Digital jukebox device with karaoke and/or photo booth features, and associated methods

ABSTRACT

Certain exemplary embodiments relate to entertainment systems and, more particularly, certain exemplary embodiments relate to jukebox systems that incorporate digital downloading jukebox features along with karaoke jukebox and/or photo booth features. A combined karaoke/photo booth/jukebox may enable more integrated performance-like experiences in an in-home or out-of-home location or venue. By leveraging vast audio media libraries, trusted rights-respecting network infrastructure, and on-site image/video capturing from integrated recorders and/or remote portable devices, a more sociable experience may be created for karaoke jukebox patrons, e.g., where custom content can be generated and shared in a safe and legally appropriate manner.

CROSS-REFERENCES TO RELATED APPLICATIONS

This application is a continuation of U.S. application Ser. No.16/774,323 filed Jan. 28, 2020, which is a continuation of U.S.application Ser. No. 16/293,524 filed Mar. 5, 2019, now U.S. Pat. No.10,582,240 issued Mar. 3, 2020, which is a continuation of U.S.application Ser. No. 14/041,309 filed Sep. 30, 2013, now U.S. Pat. No.10,225,593 issued Mar. 5, 2019, which is a continuation of U.S.application Ser. No. 13/621,922 filed Sep. 18, 2012, now U.S. Pat. No.9,324,064 issued Apr. 26, 2016, which claims the benefit of ProvisionalApplication Nos. 61/584,750 filed on Jan. 9, 2012, and 61/536,015 filedon Sep. 18, 2011, the entire contents of each of which is herebyincorporated herein by reference in this application. This applicationalso incorporates by reference the entire contents of application Ser.No. 12/929,466 filed on Jan. 26, 2011 now U.S. Pat. No. 9,521,375 issuedDec. 13, 2016; Ser. No. 12/737,395 filed on Jan. 7, 2011 now U.S. Pat.No. 8,849,435 issued Sep. 30, 2014; 61/202,617 filed on Mar. 18, 2009;Ser. No. 12/318,864 filed on Jan. 9, 2009 now U.S. Pat. No. 8,332,887issued Dec. 11, 2012; Ser. No. 12/222,785 filed on Aug. 15, 2008; Ser.No. 12/076,761 filed on Mar. 21, 2008 now U.S. Pat. No. 9,953,481 issuedApr. 24, 2018; Ser. No. 11/902,790 filed on Sep. 25, 2007 now U.S. Pat.No. 9,171,419 issued Oct. 27, 2015; and Ser. No. 11/902,658 filed onSep. 24, 2007 now U.S. Pat. No. 10,373,420 issued Aug. 6, 2019.

TECHNICAL FIELD

Certain exemplary embodiments relate to entertainment systems and, moreparticularly, certain exemplary embodiments relate to jukebox systemsthat incorporate digital downloading jukebox features along with karaokejukebox and/or photo booth features.

BACKGROUND AND SUMMARY

Jukeboxes have been around for decades and provide users with theability to select desired music for reproduction in a convenient andadvantageous manner. Jukeboxes conventionally have been provided incommercial establishments, such as restaurants and bars, in order toprovide desired music on demand for patrons thereof for a fee. Over thelast several years, a new generation of jukebox devices have becomeavailable that provide significant improvements in the operation thereoffor all parties involved. More specifically, the conventional standalonephonorecord and CD jukeboxes are being replaced by digital downloadingjukeboxes that are controlled by and communicate with a central server.An example of this new generation jukebox system is shown in U.S. Pat.No. 6,308,204, the entire disclosure of which is incorporated herein byreference. A leading provider of this new generation of jukebox systemsis TouchTunes Music Corporation.

FIG. 1 shows an overview of an exemplary embodiment of a digitaldownloading jukebox system 10. As shown in FIG. 1, the jukebox system 10includes a central server 12 that contains a master library of audiocontent (typically music), as well as or alternatively audiovisualcontent (typically music and associated video or graphics), that can bedownloaded therefrom. The jukebox system also includes a series ofremote jukebox devices 16, 16 a-16 f Each of these jukebox devices aregenerally located in a bar, restaurant, club, or other desired location,and are operable to play music (e.g., from a suitable storage locationsuch as, for example, from a local server, a central and potentiallyremote server, from local storage, etc.) in response to receiving apayment from a user, such as coins, bills, credit/debit card, etc., andhaving one or more songs selected by the user for play. In analternative embodiment, a music service is paid for on a subscriptionbasis by the location, and the selected music is free for the end-user.The jukebox device 16 typically includes a screen 18 that presentsinformation to the user and allows the user to select songs therefrom,as well as an audio system 20 that plays the selected songs. The screen18 may also be used for displaying song-related video or graphics. Thescreen 18 may also be used to display advertisements for the jukeboxitself in order to attract customers thereto, to display other types ofadvertisements, and/or to display any other desired information.

The jukebox devices 16 (sometimes referred to herein as simply“jukeboxes”) are operable to communicate with the central server 12through a communications network 14, such as, for example, the Internet.The jukeboxes 16 periodically communicate with the server 12 in order toprovide information to the server 12 regarding the specific songs thathave been played on the jukebox. The central server then uses thisinformation in order to determine the appropriate royalties and/or otherpayments that are owed for songs played on each jukebox. Thus, oneadvantage of this new generation of jukeboxes is that the soundreproduction and/or other applicable music rights can be adhered to in amore accurate and reliable manner, thereby assuring the proper royaltiesare paid to the artists or music owners. The central server 12 can alsoprovide new songs to the jukebox 16 in order to assure that theappropriate or most popular songs are maintained on the jukebox based onthe specific customers at that location. Thus, the songs available oneach jukebox can be customized through communication with the centralserver in order to provide the songs and/or types of music thatcustomers generally request at each jukebox location. As described inthe above-referenced U.S. Pat. No. 6,308,204, the central server canalso advantageously be used to update the operating software on thejukeboxes in order to, for example, change the operation of the jukebox,such as to provide new or improved features. Thus, another advantage ofthis new generation of jukeboxes is that the songs (or other audioand/or visual content), and the operation of the jukebox itself can beremotely changed as desired without the need to have someone (such as arouteman) personally service the jukebox. Instead, such updates can bedone using the central server 12.

As indicated above, the jukebox devices 16 each include a mass storagedevice, such as a hard drive, which stores the songs and associatedvideo/graphics data (if any), as well as any other desired graphicalinformation for reproduction on the jukebox. The mass storage device ofthe jukebox typically has limited storage capacity relative to thestorage device of the central server 12. As a result, only a fraction ofthe songs stored on the central server are typically stored on the massstorage device of the jukebox at any one time. There may be otherreasons as well, such as for security of the data or limited room in thejukebox itself, for having limited storage capacity on the jukeboxand/or limiting the number of songs stored thereon. For example,physical space may be limited on wall-mount jukeboxes or the like, whichare designed to be small in size as compared to free-standing models. Asexplained above, the songs on the jukebox can be changed throughcommunication with the central server, but typically any one jukeboxonly stores a relatively small subset of the complete library of songsmaintained by the central server at any one time.

In order to increase the revenue that a jukebox generates, making themost desired or popular songs available on the jukebox over time may beseen as an advantage. If customers cannot find songs they like on thejukebox, usage of the jukebox (and the revenue generated thereby) candecrease. On the other hand, it is not always possible to predict inadvance exactly what a customer at any particular location will desireto play on the jukebox. In fact, there are likely many instances where acustomer would have selected a song that exists on the central serverbut is not currently present on the jukebox. As a result, the jukeboxmay not be enjoyed and used to its fullest extent. In order to addressthis problem and increase revenue, jukebox systems have in the pastprovided a feature that enables the user to search for songs on thecentral server from the jukebox and request an immediate download of adesired song from the central server to the jukebox for an additionalfee. This feature enables the user to play any song in the masterlibrary of songs maintained by the central server using the jukebox,regardless of whether or not the specific song is presently stored inthe mass storage of the jukebox itself. Thus, the user can first lookfor desired songs on the local storage of the jukebox and then, ifdesired, search further on the central server for desired songs (e.g.,in connection with search functionality, potentially accessible byselecting a central server search function button on the screen). Thejukebox device typically charges an additional fee (such as five creditsinstead on one credit) for an immediate download and play of a song fromthe central server as opposed to a standard play directly from thejukebox's local storage.

In addition to all the features of a conventional jukebox, there is aneed for an integrated karaoke experience. In that regard, currentjukeboxes typically are turned off or otherwise deactivated duringkaraoke nights, where karaoke providers bring in their own separateequipment and set it up at the venue, or the venue itself simply sets upthe separate karaoke system in which it has separately invested. Thedeactivation of the jukebox device, even if only temporary, represents aloss of potential revenue during such karaoke establishments. The setupand tear-down of the separate karaoke systems also is inconvenient andsometimes burdensome, e.g., for short-staffed venues, for venues wherethere is not a lot of space, etc. Moreover, conventional jukeboxes havebeen largely shut out from “karaoke-only” establishments. Becausejukeboxes and karaoke device belong in different classes in the realworld, a whole market remains unavailable and thus untapped.

As is known, the karaoke environment involves an organized process ofselecting music from an exclusive karaoke catalog that contains legallylicensed music. Unfortunately, it has been very challenging to develop asufficiently feature-rich solution to allow a true karaoke experience totake place in a bar or public venue. Karaoke systems in place today forcommercial uses typically present music that the “KJ” or “KaraokeJockey” (as opposed to the “DJ”) has accumulated. It has been observedthat few KJs make any effort to obtain legally licensed versions of thesongs that make use of Even genuine efforts to license songs fromappropriate karaoke music suppliers are fraught with risk, as thesuppliers themselves oftentimes do not have coherent and effectivelicensing capability. And even genuine efforts to license songs stillcannot provide to KJs the vast music catalog available on jukeboxdevices.

Thus, it will be appreciated that there is a need in the art for a newcatalog management and royalty payment strategy that goes beyond whathas been put in place for conventionally licensed music for mechanicalreproduction and performance, e.g., so as to accommodate karaokeenvironments. For instance, certain exemplary embodiments provide a wayto comply with obligations to respect author rights, in the morecomplicated karaoke environment where a different set of rights isimplicated, e.g., in connection with vocal elimination and replacement,generation of new content, etc.

In this vein, as is known, the karaoke experience creates a new work,namely, a combination of the original music and the performer(s)singing. There oftentimes is a desire for performers to retain audio oraudio and video copies of their performances. To meet this need,however, would imply the potentially recurring usage of the originalmusic track and the appropriate tracking and management of theseproduced works, e.g., to comply with current copyright laws. Thus,another challenge facing the development of a karaoke applicationinvolves providing the ability to create these new performance works,while also managing them in a manner that respects the licensing demandsof the original rights holder(s). Media management, however, is hamperedcurrently, as digital media and ubiquitous player technology has becomewidespread.

One aspect of certain exemplary embodiments relates to providing, in thevenue or location corresponding to the physical jukebox and karaokeenvironment, the ability to seamlessly transition between conventionaljukebox usage or, jukebox plus broadcast TV (as in using the jukeboxaudio system to play the sound for a football game being presented onthe venues televisions), and/or a new karaoke-appropriate audio andvideo configuration. In so doing, it may be desirable to makeadjustments to a number of settings of the combined karaoke jukeboxsystem.

For instance, the volume settings for all zones may be altered to fairlypresent the stage environment and provide the performer with suitableaudio monitor capability. In addition, video screens may be repurposedto provide information about upcoming performers and lyrics for thecurrent song. As alluded to above, it would be desirable to have thistransition take place in a seamless manner, demanding very little skillfrom venue staff or the karaoke master of ceremonies or the de facto“KJ.”

Thus, it will be appreciated that there is a need in the art fortechniques for improving jukeboxes by also incorporating karaokefeatures that provide karaoke performs a “take-away” while addressinglicensing, reporting, and/or other requirements, both at and away fromthe venue and location, while also enabling for a seamless transitionbetween jukebox and karaoke modes of operation.

The inventors of the instant application have recognized that karaokecan be a positive, social, experience that is fun and sometimes evencompetitive. Performance is a part of the karaoke experience, for bothperformers and the audience. The more people involved in the experience,the more fun it tends to be. Smart technology can provide new KJfeatures. Smart technology also can leverage opportunities to create aconnected karaoke experience for a connected world.

Thus, an aspect of certain exemplary embodiments relates to encouragingmore people to perform, and/or connecting more people to theperformance—before, during, and/or after a performance.

An aspect of certain exemplary embodiments relates to providing akaraoke jukebox connected system with collaborative touch points(including, for example, user devices such as mobile phones, tablets,etc.; jukeboxes themselves; game or other fixed or portable terminals ina location; etc.) that define unique moments.

Another aspect of certain exemplary embodiments relates to treating aperformance as a moment of the karaoke experience that other momentsboth lead to and stem from.

Another aspect of certain exemplary embodiments relates to definingmoments in the experience by providing unique or signature interactionsthat help make the experience immersive and unique for patrons, whetherthey are performing or watching at the location or remote from thelocation.

Certain exemplary embodiments relate to a jukebox device usable in ajukebox mode, and (a) a karaoke mode, and/or (b) a photo-booth mode, asshown and described herein.

Certain exemplary embodiments relate to a method for operating a jukeboxdevice usable in a jukebox mode, and (a) a karaoke mode, and/or (b) aphoto-booth mode, as shown and described herein.

Certain exemplary embodiments relate to a system including a jukeboxdevice usable in a jukebox mode, and (a) a karaoke mode, and/or (b) aphoto-booth mode, as shown and described herein.

In certain exemplary embodiments, a method of recording a karaokeperformance in which a karaoke performer sings a song through a firstmicrophone connected to a jukebox that is playing the song is provided.A user can check in to a site where the jukebox is located via anapplication running on a portable electronic device being operated bythe user. The application has access to a karaoke queue maintained bythe jukebox, with the karaoke queue indicating the songs that are beingsung. There is a synchronizing of times as between the jukebox and theelectronic device upon said check in. The electronic device is caused tocapture at least video of the karaoke performance mediated by thejukebox. The captured video is received from the electronic device at anetwork location. At the network location, the captured video iscombined, with reference to the synchronized times, with high-qualityaudio captured by the first microphone connected to the jukebox andhigh-quality song audio corresponding to the song associated with thekaraoke performance, in order to create a combined recording of thekaraoke performance.

In certain exemplary embodiments, a method of generating a filecorresponding to a performance in which a performer sings a song withbackup instrumentation is provided. Audiovisual data captured from auser device is received, with the audiovisual data including first audiodata and first video data. Audio-only data having a quality higher thanthe first audio data is received. The first audio data and theaudio-only data are digitally combined such that the first audio data isat least partially replaced with the audio-only data in order to producea new audiovisual data file with user-generated video contentsynchronized with high-quality audio content based on a common timereference value.

According to certain exemplary embodiments, non-transitory computerreadable storage mediums tangibly store programs that, when executed,implement these and/or other methods.

Similarly, according to certain exemplary embodiments, systems areconfigured to implement these and/or other methods. For instance, incertain exemplary embodiments, a digital jukebox system is provided. Inthe system, there is provided a digital jukebox device comprisingprocessing resources including at least one processor and a memory, withthe processing resources being configured to cause the digital jukeboxdevice to operate in standard jukebox and karaoke jukebox modes. Thestandard jukebox mode is programmed to cause the digital jukebox deviceto reproduce instances of media when corresponding payments have beenmade. The karaoke jukebox mode is programmed to cause the digitaljukebox device to enable a karaoke performer to participate in a karaokeperformance in which the karaoke performer sings a song through a firstmicrophone connected to the digital jukebox device that is playing thesong. A check-in module is configured to enable a user to check in to asite where the digital jukebox device is located via an applicationrunning on a portable electronic device being operated by the user, withthe application having access to a karaoke queue maintained by thedigital jukebox device, the karaoke queue indicating the songs that arebeing sung. A synchronization module is configured to cause time to besynchronized as between the digital jukebox device and the electronicdevice upon said a successful check-in operation performed in connectionwith the check-in module. A non-transitory computer readable medium isconfigured to receive, via the application, at least video of thekaraoke performance mediated by the jukebox captured by the electronicdevice. A mixer is configured to combine, with reference to thesynchronized times, the captured video with high-quality audio capturedby the first microphone connected to the jukebox and high-quality songaudio corresponding to the song associated with the karaoke performance,in order to create a combined recording of the karaoke performance.

The exemplary embodiments, aspects, and advantages disclosed herein maybe provided in any suitable combination or sub-combination to achieveyet further exemplary embodiments.

BRIEF DESCRIPTION OF THE DRAWINGS

These and other features, aspects, and advantages of the instantinvention will be further understood by review of the following detaileddescription of the exemplary embodiments when read in conjunction withthe appended drawings, in which:

FIG. 1 is a block diagram of a conventional downloading digital jukeboxsystem;

FIG. 2 is a block diagram of an exemplary embodiment of an improvedjukebox system 10′;

FIG. 3 is a schematic view of a combined jukebox karaoke system for usewithin a venue or location in accordance with certain exemplaryembodiments;

FIG. 4 is an example karaoke jukebox remote control usable in connectionwith certain exemplary embodiments;

FIG. 5 shows example performance data associated with a karaokeperformance on a karaoke jukebox in accordance with certain exemplaryembodiments;

FIG. 6 is a flowchart showing an illustrative process for logging into akaraoke jukebox, selecting a song to be performed, and optionallyuploading data to a social networking site, in accordance with certainexemplary embodiments;

FIG. 7a is a flowchart showing an illustrative process for combiningcaptured audio, image, and/or video content, in accordance with certainexemplary embodiments;

FIG. 7b is a flowchart showing an illustrative “use case” for aperformer competing a karaoke performance at a venue in accordance withcertain exemplary embodiments;

FIG. 8 is an audio-video sequencing system in accordance with certainexemplary embodiments;

FIG. 9 a flowchart showing an illustrative process for scoring a karaokeperformance, in accordance with certain exemplary embodiments;

FIG. 10 is a flowchart showing an illustrative process for adjustingaspects of a karaoke performance, in accordance with certain exemplaryembodiments;

FIG. 11 is a flowchart showing an illustrative process for using arehearsal package in accordance with certain exemplary embodiments;

FIGS. 12a-12f show a first use case pertaining to first time songqueuing in accordance with certain exemplary embodiments;

FIGS. 13a-13f show a second use case pertaining to smart songsuggestions in accordance with certain exemplary embodiments;

FIGS. 14a-14f show a third use case pertaining to performing a song inaccordance with certain exemplary embodiments;

FIGS. 15a-15d show prompts for actions to be undertaken during aperformance that may be provided in accordance with certain exemplaryembodiments;

FIGS. 16a-16f show a fourth use case pertaining to audience engagementin accordance with certain exemplary embodiments;

FIGS. 17a-17f show a fifth use case pertaining to socializing thekaraoke experience in accordance with certain exemplary embodiments;

FIGS. 18a-18f show a sixth use case pertaining to performer engagementin accordance with certain exemplary embodiments;

FIGS. 19a-19f show a seventh use case pertaining to performer engagementin accordance with certain exemplary embodiments;

FIG. 20 shows an example countdown screenshot in accordance with certainexemplary embodiments;

FIG. 21 shows an example photo burst screenshot in accordance withcertain exemplary embodiments;

FIG. 22 shows an example screenshot displaying an electronic or digital“proof sheet” in accordance with certain exemplary embodiments;

FIG. 23 shows an example screenshot allowing frames to be added to animage in accordance with certain exemplary embodiments;

FIG. 24 is a flowchart demonstrating steps in recording a performance orother event in accordance with certain exemplary embodiments;

FIG. 25 is a block diagram of illustrative components of an uploadsystem in accordance with certain exemplary embodiments;

FIG. 26 is a partial schematic view of a performance archive inaccordance with certain exemplary embodiments;

FIG. 27 is a simplified schematic view of a mobile user using a mobileapplication to record a portion of a performance in accordance withcertain exemplary embodiments;

FIG. 28 is a partial schematic view of a performance archive foruser-based recordings in accordance with certain exemplary embodiments;

FIG. 29 is a schematic view showing mobile audio clip matching andre-mixing techniques in accordance with certain exemplary embodiments;and

FIG. 30 is a schematic view showing a mobile video file being viewedfrom a cloud or other network location in accordance with certainexemplary embodiments.

DETAILED DESCRIPTION OF EXEMPLARY EMBODIMENTS

Referring now more particularly to the drawings, FIG. 2 is a blockdiagram of an exemplary embodiment of an improved jukebox system 10′.The jukebox system 10′ includes similar elements as shown in FIG. 1 anddescribed above, including a central server 12 connectable tocommunications network 14 and to remote jukebox devices 16, 16 a-16 f.However, the jukebox system 10′ further includes local servers 22, 22a-22 f respectively connected to each of the jukebox devices 16, 16 a-16f. The central server 12 includes a master library of songs (and/orother content). Each of the jukebox devices includes a subset of themaster library on a local storage device of the jukebox. The centralserver may be used to individually manage the contents of the jukeboxdevice, by monitoring usage of and updating the subset of songs on eachof the jukebox devices with the intent of maximizing the usage thereof.The central server 12 periodically receives data from each of thejukeboxes for the purpose of royalty accounting and payment for songsplayed. The jukebox devices may connect to the network in any suitablemanner, such as dial-up modem or broadband modem (e.g., DSL, cable,wireless broadband, or satellite). The communications network 14 may beany suitable network capable of distributing data (e.g., audiovisualdata) from the central server 12 to the jukeboxes 16 and enabling datato be uploaded from the jukeboxes 16 to the central server 12.

The songs (and/or other data) may be digitized, compressed and encryptedby the central server 12 prior to sending songs to the jukeboxes forsecurity and bandwidth purposes using known techniques. The songs arethen decompressed and decrypted by the jukeboxes for storage andreproduction thereon. Thus, each of the jukeboxes maintains in adatabase a library of digitized songs for play on the jukebox, whereinthe library can be changed or updated through communication by thecentral server. The jukeboxes may also receive and store dataconstituting images (e.g., still and/or moving video and/or graphicalimages) that can be displayed on the display 18 of the jukebox device16. In one exemplary embodiment of the invention, the jukebox deviceshave similar structure and operation described in U.S. Pat. No.6,308,204 referenced above. Thus, the jukebox devices 16 each mayinclude one or more microprocessors, such as a main CPU and an audioDSP, a memory, such as a hard drive, for storing songs and/or othercontent, a display of displaying visual items, an audio arrangement 20for providing audio, a communication system for enabling the jukebox tocommunicate with the central server 12 through the communicationsnetwork 14, and operating software, including a multitasking operatingsystem, that controls the operation of the jukebox. The operatingsoftware also may be updateable through communication with the centralserver 12 as described, for example, in U.S. Pat. No. 6,308,204referenced above. The jukeboxes 16 further include one or more paymentdevices, such as coin, bill and/or credit card input devices, forenabling a customer to pay for usage of the jukebox device in aconvenient manner. The screen 18 may be an interactive device such as,for example, a touch screen that enables the user to input selections bytouching the screen. Each jukebox device has, in one embodiment, a localserver 22 that can be accessed by the jukebox device. The local serversare respectively connected to the jukebox devices using Ethernet orother type of local connection. In another embodiment, the local servermay simply be a logical extension (e.g., partition, directory, or area)of the jukebox's hard drive, rather than a separate hardware device. Thelocal servers 22 may each include a mirror copy of the master library ofmusical recordings maintained by the central server 12. The local server22 can be loaded with the master library by the entity that owns and/orcontrols the jukebox network prior to shipping the local server andjukebox device to the jukebox distributor or operator. Of course, overtime, the local sever will no longer correspond identically to thecentral server, due to the fact that the central server may becontinually updated with additional or new songs. Thus, the localservers 22 also may be updated periodically to maintain a correspondencewith the library on the central server 12. This updating can be done,for example, by the central server 12 through communication with thejukebox devices connected with the local servers 22 using, for example,either dial-up or broadband modems. Alternatively, the updating can bedone personally with an update tool that can be connected by a routemanor other person directly to the jukebox or local server for the purposeof updating the contents of the local server. The portable tool couldinclude a removable storage medium, such as a hard drive, that could bereturned to and reused by the owner of the jukebox system for futureupdates. The tool itself could be kept by the operator or other personin charge of maintaining specific jukeboxes for use upon receipt of theupdated removable storage medium from the owner of the jukebox system.

For security reasons, the local server 22 may not include all of thedigital data that constitutes any one song that is stored on the localserver 22. In addition, the part of the song that is on the local serveris encrypted. The jukebox device 16 contains the missing part of each ofthe songs on the local server, thereby enabling the jukebox to assemblethe complete song based on the contents of the local server and thememory on the jukebox device. The missing data located on the jukebox isneeded in order to decrypt the songs. For example, a single block (orother small fraction) of data for each song may be missing on the localserver but present on the jukebox device, and the encryption may bebased on the missing block and may proceed on a block by block basis.Thus, none of the blocks can be decrypted without obtaining and/ordecrypting a preceding block. This feature provides significant securityand prevents or deters theft or other type of unauthorized use orcopying of the songs on the local server. Thus, in this embodiment, eachlocal server must be specifically assigned to a specific jukebox deviceso that the decryption described above can be properly performed. Inaccordance with an exemplary embodiment, the local servers may also eachbe individually registered with and identified to the central server 12,so that the central server can individually manage and monitor eachlocal server. The same is true for the jukebox device itself, i.e., itmay also be registered with the central server so that it too can beindividually monitored and managed by the central server. As will beunderstood from the foregoing description, the local servers become animportant and advantageous part of the jukebox system by allowing thecontents thereof to be accessed by the jukebox device to provideadditional services (such as providing additional songs) not availableon the jukebox device itself. As will be explained below, the songlibrary of the central server and/or the storage capacity itself can beadvantageously used to provide services to other jukeboxes, such asfee-based residential and commercial jukeboxes and/or other fee-basedequipment. One use of the local servers may be to provide an immediatesong downloading feature. FIG. 3 is a schematic view of a combinedjukebox karaoke system for use within a venue or location in accordancewith certain exemplary embodiments. Elements shown below the dashed linein FIG. 3 are provided in a single venue or location, whereas elementsshown above the dashed line are provided outside of that venue orlocation. It will be appreciated that multiple venues and/or locationsmay be connected to the AV Network, for example, although multiple suchkaraoke jukebox systems and/or related components are omitted from FIG.3 for clarity purposes. Also, it will be appreciated that one or morekaraoke jukebox systems, displays, speakers, zones, mobile devices,remote devices, social networks, and/or the like, may be provided indifferent locations and that the numbers of the various elements shownin FIG. 3 are provided for explanatory purposes. In other words, more orfewer mobile devices, displays, remote devices, social networks, may beconnected or interconnected in different embodiments.

As shown in FIG. 3, a karaoke jukebox system 302 is connected to anaudiovisual (AV) network 304. The karaoke jukebox system 302 includesprocessing resources 306 (e.g., at least one processor, a memory, anon-transitory computer readable storage medium, and/or the like) thatmay help execute modules used in karaoke, jukebox, photo booth, and/orother operating modes. The AV network 304 also may include processingresources 308 (including, for example, at least one processor, a memory,a non-transitory computer readable storage medium, and/or the like). Thekaraoke jukebox system 302 may include a songs database 310, a songqueue 312, and a process or module to manage such database and queue. Itwill be appreciated that the songs database 310 may be provided on alocal server in certain exemplary embodiments. Similarly, the karaokejukebox system 302 may include a lyrics database 314 and a karaoke queue316, e.g., to help manage operations when the karaoke jukebox system 302is operating in karaoke mode. In certain exemplary embodiments, thelyrics database 314 may be located at a remote location and thus may beaccessible over a suitable network connection.

The songs to be used for karaoke may be stored in the songs database 310in certain exemplary embodiments. However, in different exemplaryembodiments, the songs to be used for karaoke may be stored in adatabase separate from the songs database 310. That separate databasemay be a part of, or at least accessibly by (e.g., from a remotelocation) the karaoke jukebox system 302. In still other exemplaryembodiments, songs from the song database 310 may be used for karaoke,e.g., if a vocal eliminator or other transform is applied so as tosuitably reduce (and sometimes even eliminate) some or all of the mainvocal tracks in the song. Of course, the vocal eliminator may bebypassed when the jukebox is operating in its normal jukebox mode. Incertain exemplary embodiments, these features may be combined in variouscombinations and/or sub-combinations. For instance, two or more databaseof karaoke songs may be provided separate from the songs database 310,e.g., with one database of karaoke songs being available on the karaokejukebox system 302 and another database of karaoke songs being locatedremote from, but still being accessible and managed by, the process ofthe karaoke jukebox system 302. A premium or at least increased numberof credits may be charged for accessing songs from the remote databaseof karaoke songs, e.g., as specified in a fee table and as read by thesystem 302 when modes are changed and a selection is made in arespective mode. In certain exemplary embodiments, another premium maybe charged for selecting a song from the “regular” songs database 310and then applying the vocal eliminator or other transforms to it, alsopotentially as specified in the fee table. This second premium may behigher than the first premium in certain exemplary embodiments.

Metadata may be associated with songs in the karaoke database orcatalog. Such metadata information may include, for example, lyrics of asong, rated difficulty, key, range, snippet (e.g., available forplayback on a mobile device), an indication as to when the song was lastplayed at a given location or venue, its popularity, frequency of play,etc. This and/or other information may be used in helping to developrecommendations for patrons in general or patrons who are recognizedjukebox and/or karaoke users (e.g., based on their known favorites,known vocal ranges, etc.), when a recommendation function of the jukeboxis activated by the patron, when the patron logs into the jukebox, etc.

In certain exemplary embodiments, a simple karaoke and/or song queue maybe maintained. However, in certain other exemplary embodiments, apriority queue may be maintained, e.g., based on additional creditspaid. Additionally, or in the alternative, smart queuing may help togroup similar or dissimilar songs or songs that sound good together in agroup (e.g., a medley of different songs), space apart duplicates,delete duplicates, space apart or move together songs that are known toget a good crowd reaction, etc. A program or program modulecorresponding to this smart queuing function may implement this dynamicreordering based on, for example, popularity scores associated with thesongs, beat counts or known tempo data (e.g., retrieved from a metadatasource including such information) saved in the database or otherwiseknown ahead of time, artist/album/song title data, and/or the like. Toaccommodate network connections, the karaoke jukebox system 302 mayinclude a network interface 318, which connects the karaoke jukeboxsystem 302 to the AV network 304 and/or other outside resources. Thenetwork interface 318 of the karaoke jukebox system 302 also mayaccommodate connections to patrons' mobile devices 320. It will beappreciated that such connections may be direct connections to thekaraoke jukebox system 302 or indirect connections, e.g., mediated bythe AV network 304, a local server, and/or the like.

Audio may be output from the karaoke jukebox system 302 using one ormore audio output ports and/or circuits 322. The audio output 322 maysupport zoned output, e.g., to multiple speakers and/or speaker systems324. The operating system of the jukebox may maintain separate songand/or karaoke queues for the various zones in certain exemplaryembodiments. For instance, separate queues may be maintained so thatsongs may be played in certain zones even though other zones are playingdifferent songs and/or are participating in karaoke. Auxiliary and/ormicrophone input ports 326 may facilitate one or more microphoneconnections, e.g., for karaoke, general announcement and/or otherpurposes. A camera 328 integral with or otherwise connected to thekaraoke jukebox system 302 may be configured to capture images and/orvideos, e.g., for use in photo booth and/or other modes (and in somecases at least temporarily stored on a storage location of the jukeboxdevice). For example, the camera may be used for custom attract loops(e.g., where images and/or video from the location are captured andincorporated into standard attract videos/images at predefined or othertimes), security purposes, etc. A video output circuit 330 mayfacilitate connections to multiple displays 332, e.g., through aswitching device 334 as described herein.

A storage location of the AV network 304 may include a master catalog336 of instances of media available for playback on the karaoke jukeboxsystem 302. This may include, for example, songs, advertisements,attract media clips, and/or the like. The AV network 304 also mayinclude a social network interface 338, enabling connections to be madeto one or more social networks 340 (such as, for example, myTouchTunes,Facebook, Twitter, LinkedIn, etc.). One or more remote devices 342 maybe able to connect with the AV network 304, the social networks 340,and/or the karaoke jukebox system 302 (e.g., directly or using the AVnetwork 304 as an intermediary) in certain exemplary embodiments.

In different scenarios, a KJ may be a member of the venue staff, anenthusiastic audience participant, an operator, or an automated(machine) controller in different exemplary embodiments. A human usermay, for example, operate a simple remote control or remote controlledequipped smart device, e.g., to manage the sequence of subsequentperformers, make a simple audio adjustments, and provide spontaneousevent related commentary or supplemental audio and video clips orsegment initiation. In example use cases, a control system may be usedto move a nervous performer back in the queue, raise or lower the volumefor a particular performer, play prerecorded applause or cheering,display encouraging or amusing comments on the video display systems,skip performers who are no longer present (e.g., because they have leftthe venue, are not available, have decided to skip their performance,etc.), and/or the like. Human KJs may be located at or remote from thevenue in different example scenarios.

An example karaoke jukebox remote control usable in connection withcertain exemplary embodiments is shown in FIG. 4. The example karaokejukebox remote control shown in FIG. 4 may have a plurality of buttonsor switches. For instance, volume controls 402 and 404 may be used toincrease and decrease the microphone volume, respectively. Other buttons(not shown) may be used to adjust the background music, etc. The KJ mayuse dedicated buttons, menus, or the like, to cause encouraging messagesto be displayed to a display visible by the performer and/or theaudience. For instance, the KJ may trigger random “good” or encouragingmessages, and “bad” or taunting messages to be displayed by pressing thegood and bad message buttons 406 and 408, respectively. In certainexemplary embodiments, a KJ may have dedicated buttons for dedicatedmessages. Alternatively, or in addition, in certain exemplaryembodiments, the karaoke jukebox remote control may have a keypad orother input mechanism so that the KJ can input custom messages or selectfrom a catalog of predefined custom messages. The KJ may cause theperformance to be recorded by pressing the record button 410, and maycause the music and/or recording to be paused by pressing the pausebutton 412. A KJ may skip a performer by pressing the skip button 414,e.g., if the performer is not there or has not checked in (e.g., via anSMS or email message, by talking to the KJ prior to the performance,etc.) The KJ also may trigger canned applause or other effects bypressing the applause button 416 or the like. The karaoke jukebox remotecontrol may have a remote transmitter that operates under infrared, RF,Bluetooth, or other frequencies to communicate with the karaoke jukeboxsystem for these and/or other purposes. In certain exemplaryembodiments, the karaoke jukebox remote control may include a microphoneconnected to the karaoke jukebox system and/or speakers in the venue,e.g., so that KJ can make announcements, offer verbal words ofencouragement, call the next performer, etc. It will be appreciated thatthe example remote control may have these and/or other buttons orswitches for controlling the jukebox in either or both of jukebox andkaraoke modes. In certain exemplary embodiments, the KJ's remote controlmay be a virtual remote control accessible via an electronic device suchas, for example, a laptop, smart phone, tablet, or the like.

In certain exemplary embodiments, the jukebox, operating in a karaokemode, may be configured to take over one or more peripheral displaysconnected to the jukebox, e.g., by sending a karaoke alert signal andoverriding the video source.

Because the display systems within a venue may be prewired and becauseit has been observed that the staff of a location typically does notwant to be involved in potentially tedious management of the displays(which may be televisions in some example setups), it would be desirableto provide a technique for initiating karaoke and having the displaysthe location owner has chosen to automatically switch from the broadcastvideo feed to the karaoke feed. Certain exemplary embodiments thereforemay incorporate a small computing device, sometimes referred to hereinas a switching device (e.g., switching device 334 in FIG. 3), betweenthe existing video or audio-video feed from the satellite, cable,internal broadcast source, or other video feed, and the display device.In “normal” broadcast mode, television signals may pass through theswitching device. However, when the jukebox is switched into karaokemode, a control signal may be sent to the switching device, which thenoverrides the inbound broadcast source and replaces it with video and/orimages to support the karaoke experience. One or more TVs may beconnected to the single switching device, thereby allowing the abilityto cascade the display to many televisions, with potentially allrendering the same karaoke video signal. In certain exemplaryembodiments, the control signal may have information embedded thereinindicating which displays are to be switched to karaoke mode, and whichare not. The switching device may read or decode this signal and causethe correct video signal(s) to be transmitted to the appropriatedisplay(s).

A data stream of lyrics, performance, and/or other data may be createdfor display on an associated display device. This information may becreated by the jukebox, the switching device, a video server, or someother device. The created data may include, for example, an ongoingdisplay of upcoming performers, information about the currentperformance (e.g., lyrics, performer identifier, song identifier, etc.),comments about previous performers, the experience in the venuegenerally, etc. A data stream of lyrics and performance data in certainexemplary embodiments may be displayed on or via the karaoke jukeboxalone, one or more displays connected to the karaoke system, portabledevices logged into the jukebox system at or remote from the venue,and/or the like.

Certain exemplary embodiments may enable a patron to search for lyricsto discover a song to sing. It will be appreciated that it would bedesirable to enable patrons to find music that they would feelcomfortable singing. Unfortunately, however, it oftentimes is difficultfor individuals to spontaneously think of a song that they would enjoysinging and/or that they could sing well (or at least enjoyably). Themore “hints” or “triggers” provided to the patron to find the song,however, the higher the likelihood that the patron will ultimately findan acceptable song and thereby volunteer to perform. Thus, certainexemplary embodiments enable patrons to search the karaoke catalog inone or more ways including, for example, by original artist, by songtitle, by genre, by key, by beats per minute, by performance type (e.g.,solo, duet, group, etc.), by year or the period when a song may havebeen popular, etc. In addition, or in the alternative, a performer maywant to sing a song about a particular subject, possibly making itappropriate for the moment (e.g., a patriot song on Independence Day, aChristmas or Hanukkah song during the month of December, abirthday-related song on a friend's birthday, etc.). Collections ofsongs may be assembled into songbooks that offer similar characteristicthat can be labeled and potentially assist the performer in finding asong. Oftentimes, performers recall only a portion of the lyrics of thesong. For these situations, patrons may be able to use a search functionto search a lyrics database for a phrase or selection of words to findsongs containing them.

Performers may identify themselves. Identification of performers may,for example, facilitate retention of performance data. Indeed, aperformance name could be provided as a casual or playful name orhandle, or simply the first name of the individual to perform. Providingperformance names also may help performers know when their turns are,e.g., if a queue is visually displayed on a suitable display device.Performance names may be used in presentations of the actualperformance, e.g., to help identify the singing “artist.” An exampletagline may be provided, with suitable text such as, for example,“Coming up next, My Way, by Dave.”

Performers also may want to “keep” or otherwise have access to theirperformances or data about their performances such as, for example, whatsong was sung, when they sang it, the location they sang it in, etc.This information may be stored in a database on the jukebox and/or inthe audiovisual distribution record, e.g., as a part of a patron'spersonal karaoke record. To maintain such a personal karaoke record, apatron may login to the jukebox system with a user id/passwordcombination, or create a new profile, and submit credentials to anauthorized station service from a social network that the performerparticipates in such as, for example, Facebook, Twitter, myTouchTunes,or the like. The karaoke jukebox system may then associate theaudio-video and performance data with the performer, e.g., by usingprofile information. Appropriate follow-on actions then may be taken onthe performer's behalf such as, for example, copying media or metadatato a remote repository for subsequent playback, posting elements of theperformance to a social network web service under the performancecredentials, etc. The posting to the social networking site may be assimple as a “Tweet” along the lines of “@Dave performing #My Way at#Michael's Bar,” potentially with an expected or actual performance timeto either “advertise” or “commemorate” the experience. Alternatively, orin addition, more content-rich data may be posted such as, for example,an audio and/or audiovisual clip of some or all of the performance.

FIG. 5 shows example performance data to be stored in association with akaraoke performance on a karaoke jukebox in accordance with certainexemplary embodiments. Each performance may be tagged with a performanceID 502, which may be a computer-generated unique alphanumeric or otheridentifier. The performance date and/or time 504 also may be specified,along with an indication as to the location or venue 506 in which theperformance is taking place. The performer's name or other identifier508 may be included in example performance data shown in FIG. 5. Thesong performed 510, as well as the optional score or rating 512 may alsobe stored. The inclusion of the location or venue 506, performer name508, and/or song performed 510 may enable searches to be made through anappropriate user interface, e.g., accessible via a mobile application ona mobile device, on a remote computer, etc., e.g., for enabling aconnection to and search on the karaoke jukebox. For instance, aparticular patron may want to review all of the songs that that patronhas (or his/her friends have) performed. A venue or location may want toview all of the performances from a particular night, rate them by scoreor other factor, and then offer a prize. A virtual head-to-headcompetition can be made based on multiple performers singing the samesong and prizes awarded accordingly. The example performance data shownin FIG. 5 and/or other information may be stored in a database on thekaraoke jukebox system and/or a central server, in certain exemplaryembodiments.

FIG. 6 is a flowchart showing an illustrative process for logging into akaraoke jukebox, selecting on a display or with a remote control a songto be performed, and optionally with a communication arrangementuploading data to a social networking site, in accordance with certainexemplary embodiments. A performer searches for a song in step S602. Thesearch may be performed based on, for example, song name, artist, album,popular or recommended karaoke songs (e.g., dynamically updated for thevenue, dynamically updated for all karaoke jukebox enabled venues, basedon a predetermined list, etc.), songs the performer has sung before,songs recommended specifically for an identified performer (e.g., basedon the performer's prior performance history, prior scores, known vocalrange, etc.). A song is selected in step S604, e.g., using the karaokejukebox system or a mobile device connected to the karaoke jukeboxsystem (such as, for example, a bar-top or wall mount terminal, a mobiledevice of the performer in communication with the karaoke jukeboxsystem, etc.). If the performer has not already been identified to thekaraoke jukebox system (e.g., by virtue of using one's own mobiledevice, having previously logged into the karaoke jukebox system, etc.),in step S606, the performer may be prompted to enter certain personalinformation (such as name, telephone number, email address, and/or thelike), e.g., so that the performer can be contacted at the right timeand in a desired manner. The performer may have the option to joinmyTouchTunes at this time. In step S608, the queue may be updated asvarious patrons perform their karaoke selections. At the appropriatetime, in step S610, the performer may be notified that it is time oralmost time to perform. An SMS, email, or other message may be sent tothe performer, e.g., based on known, entered, or other criteria incertain exemplary embodiments. In certain exemplary embodiments, some orall of the karaoke performer queue may be displayed for these and/orother purposes. In step S612, the performer sings the song. The singermay be rated or scored based on quantitative measures such as, forexample, synchronicity with the beat, deviations from the expected notesor pitches, etc., and/or more qualitative measures such as, for example,crowd reaction, measured applause, subjective scores from a KJ or otherauthorized personnel or even guest judges, etc., e.g., as determined viaa suitable measurement arrangement. Optionally, some or all aspects ofthe performance may be saved in step S614, with such aspects alsooptionally being shared. For instance, audio and/or video of theperformance may be saved and/or shared to a social networking site forlater viewing.

In certain exemplary embodiments, a karaoke player may be linked with asmart phone, tablet, or other suitable device. This may be advantageousin that it may allow patrons to see the karaoke queue, or at least aportion thereof. In some cases, patrons may want to check on theirlocations in the queue to manage their time in the venue. In othercases, patrons may want to look at the queue to determine whether it is“worth it” to sign up for a song. Integration with a mobile devicetherefore may make it possible to view the queue or a portion thereof,browse through the karaoke catalog from a “safe” location where there isnot a lot of pressure to make an immediate selection, review the lyricsof a potential song, submit credentials and/or performance name alongwith the song selection to enter the queue, watch the performance on themobile device the lyrics for the current song being performed, etc. Thesmart phone, tablet, or other computing device may interface with thejukebox device directly or via the audiovisual distribution network indifferent embodiments, e.g., to retrieve queue information, sign up fora performance, browse the catalog, etc. Thus, a remote interface may beprovided to the jukebox and/or audiovisual network, allowing the mobiledevice user to log in and access the lyrics database, karaoke queue,etc., through a customized and simplified user interface.

In certain exemplary embodiments, the time of one or more mobile devicesin a location may be synchronized with the time of the karaoke jukeboxsystem. For instance, mobile devices within the location may be able todetermine the real time, or at least an offset between the time withinthe device and the time on the karaoke jukebox or system as a whole.This synchronization may allow two or more devices within the venue topresent or capture media in a manner that is synchronized to what isbeing presented on or captured via the karaoke jukebox. This media couldbe promotional, the actual lyrics of the song and the timed visualprogression through the lyrics, games associated with karaoke or theperformer's performance, time-based quiz or voting interactions, and/orthe like. The synchronization of time between the devices may facilitatepublic workgroup contests, quizzes or surveys, etc., being completed ina fair and visually sensible manner.

Certain exemplary embodiments enable the creation of a “mixedperformance” that accepts audio from the karaoke jukebox microphone(s)input(s), as well as the backing music audio track. Thus, in certainexemplary embodiments, the karaoke jukebox offers real-time music mixingand manipulation arrangement by, for example, overlaying the inboundperformer audio while also rendering the song music media. These twoaudio streams may be mixed by the mixing arrangement together to createa merged audio file, including both original music and audio captured inthe venue. This resulting merged file may be considered a new work to betracked for royalty and rights holder properties. However, the resultingmerged file may be transferred and/or re-performed under the karaokejukebox systems' control, e.g., to facilitate rights tracking and/orroyalty sharing. Additional audio may be pre-pended or appended to themerged file, e.g., to include sponsored advertisements, informationabout the venue and/or performance, rights information, etc.

In a similar vein, a configuration arrangement of the karaoke jukeboxsystem may be used to configure the jukebox to alternatively or inaddition create a mixed performance of the microphone(s) input(s) andthe backing music, together with one or more still images in a videofile for later access. Doing so may help to create the illusion of aprofessional performance for the karaoke performer, adding to theoverall sense of enjoyment on the part of the performer. The performermay take one or more pictures on the karaoke jukebox device itself, froma connected mobile device, from an image stored on the performer'ssocial network environment, and/or other source(s). For those recordingsthat are retained, pictures may be used as graphics along with therecorded performance audio. Multiple pictures may be used in aslideshow-like fashion. In certain exemplary embodiments, the karaokejukebox system may automatically insert pictures at predefinedlocations. Such locations may include, for example, the beginning,middle, and/or end of the song. Other locations may include, forexample, automatically detected and/or predefined “transition locations”in a song (e.g., at the well known different parts of Queen's “BohemianRhapsody,” whenever a beat is dropped in Rush's “Freewill,” etc.).

In place of, or in addition, using still images, certain exemplaryembodiments may alternatively or additionally incorporate videorecordings in a video file for later access. For instance, if theperformer chose to sing into a camera in, on, or of the karaoke jukebox,it may be possible to record the video and merge it with the audio fromthe microphone(s) and the background music to generate a commonaudio-video file of the performance. This audio video file also may besubject to the rights holder's music restrictions and therefore may alsobe restricted to the ownership rights assigned to the video file by theperformer and/or the owner of the background music. The karaoke jukeboxsystem including network services may maintain control over some or allaspects of the media so as to help ensure a respect for all of thestakeholder's rights.

The video file may be made to include automated lead-in and/or lead-outaudio and/or video for later access. The lead-in/lead-out audio/videomay be stored on or accessible by the karaoke jukebox system, and theperformer may or may not select such clips in different implementations.For karaoke jukebox performances that have an associated video, theseclips may effectively serve as an “envelope” for the performance. Thismay help to create a professional looking memento of a pleasantperformance event, that optionally may be purchased for a price (e.g.,via subsequent download from the karaoke jukebox system, a socialnetworking site like myTouchTunes, retrieved via email, etc.),automatically distributed to registered karaoke jukebox users, uploadedin whole or in part to social networking sites, etc.

FIG. 7a is a flowchart showing an illustrative process for combiningcaptured audio, image, and/or video content, in accordance with certainexemplary embodiments. Audiovisual signals are captured as a song issung, e.g., in step S702. For instance, audio data may be captured usingthe microphone into which the performer is singing, thereby resulting ina high-quality capture of this portion of the performance. Theperformer's audio may be digitally or otherwise overlaid or combinedwith the background music, as that is available via the karaoke jukeboxsystem itself. Images and/or video may be captured by a camera mountedon the karaoke jukebox system, cameras set up in the location or venue,and/or mobile devices of patrons in the location or venue. Images and/orvideo clips may be selected for inclusion with the audio. It will beappreciated that pre-canned or prerecorded video clips may be included,e.g., at the beginning and/or end of the clip, during “breaks” in themusic, etc. In cases where there is only one video source, the selectionmay be made automatically. In cases where there are multiple possiblevideo sources, the performer, KJ, or other editor may select theappropriate clip(s) and/or image(s) and also indicate where they shouldbe placed in the overall stream. In other still other cases, clipsand/or images may be selected automatically on a random or non-randombasis, e.g., by determining where the performer is standing or facingand selecting an appropriate image or video clip. In step S706, theaudio and image(s) and video(s) may be synced together, e.g., based on amaster or common time reference values. Further images and/or videoclips may be pre-pended or appended in step S708. The combined videoand/or audio may be optionally uploaded, in whole or in part, to asocial media site, a common server on a remote site, made available tothe performer via a directly link emailed or other sent to theperformer, etc.

FIG. 7b is a flowchart showing an illustrative “use case” for aperformer competing a karaoke performance at a venue in accordance withcertain exemplary embodiments. In step S720, an electronic device of auser check in to a location, e.g., through a social network and/or viaan application running on the electronic device (which may be, forexample, a smart phone, tablet, or other device). In this examplescenario, the user is a friend of the person about to perform. Becausethe user is checked in at the location, the application knows who isperforming what song, when. For instance, the application may haveaccess to a karaoke song queue on the karaoke jukebox device at thelocation. The performer selects a song in step S722. The friend of theperformer may actuate a “record” button on the electronic device, atwhich point the electronic device may be caused to capture audio and/orvideo of the performance in step S724. It will be appreciated that theaudio recording may be highly directional and of a potentially lowerquality because of the hardware of the particular user's device, thelocation of the user, and the potentially high degree of ambient orbackground noise. Correspondingly, the video may be limited by where theuser points the camera. In certain exemplary embodiments, the audioand/or video data may be stored to the device and later transmitted to anetwork storage location (e.g., in the cloud) for subsequent process,e.g., as described below. In certain exemplary embodiments, the audioand/or video data may be streamed to and/or stored directly on a networkstorage location.

As the performer performs the song, audio from the performer'smicrophone may be captured. This microphone may be a high-quality inputsource and may be controlled to capture a small amount of backgroundnoise, especially when compared with the amount of background noise ofthe electronic device. The audio from the performer's microphone may bedigitally “retouched” and mixed with the underlying high-quality musicfrom the karaoke jukebox, e.g., in connection with a suitable module ofthe jukebox, a server, or other computer resource. Digital and/or othereffects may be added, for example, to add reverb, depth to the vocals,harmony lines, auto-tune features, etc. These effects may be triggeredautomatically, e.g., at predetermined points in the song, e.g., wherethe original recording originally included such features. A metadatadatabase may be consulted by the computer system doing the retouchingfor such information and optionally to trigger such effects. The digitaland/or other effects may be added by applying known filters, algorithms,transforms, and/or the like at these and/or other predefined oruser-specified times. In certain exemplary embodiments, the digitaland/or other effects may be added directly on the karaoke jukeboxitself, e.g., via a suitably configured audio manipulation modulerunning thereon. Referring once again to FIG. 7b , the audio and/orvideo from the electronic device may be mixed with the retouched audiofrom the microphone that has been overlaid onto the underlying songaudio in step S728. The combination of different audio streams fromdifferent sources may become possible because the electronic device waschecked in to the location and was synchronized with the local karaokejukebox system, e.g., thereby providing common timestamps so that thedifferent audio streams can be overlaid in a coherent fashion, even ifrecording is started and stopped one or more times, the recording fromthe microphone and the recording from the electronic device start and/orstop at different times, etc. An audio and/or video selectionarrangement may be triggered locally or remotely to determine the mixingconditions of each stream with a selected predetermined audio level.Selectively blending together the different audio streams in this waymay help create high quality audio while blending in at least some ofthe ambient sounds for a more user-generated content (UGC),personalized, or do-it-yourself feel, providing a greater sense ofpersonal ownership in the music-making process and a greater sense ofconnectedness to the venue and the particular musical event, potentiallyin a way that simulates a small or intimate “rock star like”performance. In certain exemplary embodiments, the audio streams may beblended together in equal or other proportions. A greater percentagefrom the electronic device will result in what oftentimes may beconsidered a more “amateurish” or “less professional” quality recording,whereas a greater percentage from the karaoke jukebox device will resultin what oftentimes may be considered a more professional or higherquality recording. Some, all, or none of the audio data from a givensource may be replaced with some, all, or none of the audio data fromone or more other sources. Replacing 80% of the audio from theelectronic device has been found to retain a suitable amount of ambientsound from the venue while still producing a very high quality overallsong. However, certain exemplary embodiments may replace more or lessthan 80%, e.g., as discussed above. It is noted that the replacement orblending may take place on a server in the cloud (e.g., where, or havingaccess to, the audio from the electronic device is stored, after theaudio from the karaoke jukebox device is transferred thereto or accessedtherefrom, for example), on the karaoke jukebox device itself, or someother location.

In certain exemplary embodiments, audio from multiple electronic devicesmay be combined with the higher quality audio data from the karaokejukebox system. This may be advantageous when, for example, highlydirectionalized audio is captured representing, for example, left- orright-channel audio data, e.g., by virtue of the location of the persondoing the recording. In certain exemplary embodiments, left and rightchannel audio data may be mixed in at equal parts, e.g., using asuitable interface arrangement. In other cases, the source recording(s)may be converted to monophonic data and replicated over both left andright channels. Similarly, vdata may be mixed in from the varioussources, as well. This may be advantageous, for example, if a computeralgorithm detects too much darkness, too much light, fast movements thatmight cause dizziness when played back, etc. In certain exemplaryembodiments, all audio and/or video streams may be stored for latermixing and matching, e.g., by the performer, the recorder(s), the venue,and/or others.

Still referring to FIG. 7b , once the new work is created, in step S730,a link enabling its download may be sent to some or all involvedparties. For instance, a link may be provided to the owner of theelectronic device who captured the audio and/or video, withcorresponding contact information being known by virtue of theapplication running on the electronic device; the performer of the song,with corresponding contact information being known by virtue of theperformer having provided login or other identifying credentials to thekaraoke jukebox system (directly and/or through the KJ), the KJ, thevenue, and/or other parties. In some implementations, all of thisinformation may be at least temporarily saved at a suitable storagelocation until the link is sent and/or accessed. In certain exemplaryembodiments, the links may be links to streaming media. In certainexemplary embodiments, audio and/or video files may be distributedrather than links.

In certain exemplary embodiments, the performer may be able to previewthe media before it is distributed to others, e.g., using the link,accessing information from a jukebox or other designated terminal ordevice, etc. For instance, the performer may use the correspondingdevice and a user interface thereon to designate created audio/videopackages as being available to anyone, anyone who recorded theperformance, friends only, venue only, lists or sub-lists of friendspossibly organized in groups, etc. Thus, a performer may have at leastsome control over user-generated contact that uses the particularperformer's likeness. Similarly, in certain exemplary embodiments, theowner or operator of the electronic device may designate the createdaudio/video packages as being only selectively available. These featuresadvantageously may promote privacy, help performers retain rights intheir likenesses, help provide for overall music royalty accounting,etc.

FIG. 8 is an audio-video sequencing system implementing the selectionsmade on the audio and/or video selection arrangement in accordance withcertain exemplary embodiments. A source audio stream 802 is (or multiplesource audio streams are) received from the microphone (and/orelectronic devices such as smart phones, tablets, and/or the like) andsent to an audio mixer 804, where it is combined with the backgroundmusic and/or live sounds from the crowd (e.g., from the electronicdevices). The audio mixer 804 may assign different weights to thedifferent audio streams, e.g., such that a small amount of ambient noiseis added, whereas the vocal levels are provided at a level suitable forthe underlying song being performed. This mixing produces a cleaned andcombined audio stream 806. Similarly, one or more source images and/orone or more source video streams 808 are fed to an image/video selector810. Following such selections, a cleaned and combined video stream 812is produced. The cleaned and combined audio stream 806 and the cleanedand combined video stream 812 may be provided to a sequencer 814, wherethey are mapped to one another in a coherent fashion and such that, ifcombined, they would result in a logical video file, e.g., using thesynchronized times associated with the audio and video/images. Thesequenced data is then passed to a video packager 816, where they arecombined. Optional additional content may be added via the packager 816.Such optional additional content may include, for example, pre-pended orappended audio and/or video (e.g., with advertisement, sponsor,copyright, download, and/or other information). The target audio and/orvideo file(s) 818 ultimately may be produced, and optionally uploaded inwhole or in part to a server, social networking site, or the like.

The acoustic settings of a venue may be adjusted to properly accommodatethe transition from conventional audio to karaoke audio in certainexample instances. Karaoke jukebox systems are typically installed invenues where the usage is not 100% karaoke and, as such, the audiosystems within locations may be set up through an appropriate interfaceto support various zones with a relative volume given to each his own.Because the focal point for a karaoke performance typically is the stageor area from which the patron performs, it is possible that the relativevolume for each of the zones does not correspond to acoustically logicalsetup for karaoke. Thus, certain exemplary embodiments may dynamicallyadjust the volumes for the zones so as to optimize the acoustics forkaraoke performances. For instance, plural acoustic program settings maybe provided, e.g., for accommodating live jukebox, background music,karaoke, live DJ, and/or other events. These settings may be specifiedin advance (e.g., by an operator, manager, location staff, or otherauthorized personnel) and/or dynamically adjusted (e.g., by an operator,manager, location staff, or other authorized personnel). One therelative balance is established, the plural settings may be saved to anon-transitory computer readable storage medium (e.g., of or incommunication with the karaoke jukebox system) for possible laterconsultation. Transition settings between the various modes also may besaved to facilitate switchover as between the various modes in a simplemanner.

A microphone configuration utility module may be provided to helpestablish an improved acoustic balance in the venue. Display screens maybe displayed after triggering said configuration utility and may incertain instances instruct or indicate (e.g., on a layout of theestablishment or a generic layout) to the technician where to place themicrophone(s). After the technician indicates to the configurationutility that the microphone was appropriately placed, the configurationutility may trigger (in connection with speakers) the emission of aseries of tones emitted from the various possible zones that may bereceived by the microphone's inputs and processed to establish theimproved balance and volume limits to be applied to the control circuitof the speakers. This technique may ease installation of the karaokejukebox system and help reduce the likelihood of feedback. In certainexemplary embodiments, the user may be asked to stand in a central area(e.g., a performance area) with the microphone(s). In other exemplaryembodiments, the installer may be requested to reposition themicrophone(s) in front of the various speakers installed within thelocation, listen to test signals projected from the speakers, and allowthe system to adjust the appropriate volumes and identify potentials forfeedback or poor sound quality. The configuration utility arrangementmay in certain exemplary embodiments comprise a selection display orarrangement to optionally undertake a zone-by-zone and/orspeaker-by-speaker test to be performed in certain example situations.The resulting profile may be stored and used for adjustments in volume,balance levels, etc., when the jukebox switches between modes. Thesesound equalization techniques may be similar to those provided byYamaha's YPAO system.

A module of the karaoke jukebox system of certain exemplary embodimentsmay be configured to detect a dominant melody line within a song and toallow the processor(s) of the jukebox to measure and compare theperformer to be measured against this melody line. Such a comparison maybe visually displayed for the performer and/or the audience, e.g., sothat they can compare the karaoke performance against the performancepopularized by the originating artist. This may be accomplished by, forexample, comparing the observed sound to a reference saved in thejukebox, network storage location (e.g., of the central server, from anoutside provider database, etc.), or elsewhere. In some cases, it ispossible to obtain metadata or the like that includes song performanceevaluation data, e.g., from an outside source such as, for example, adatabase maintained by a separate provider, a store of pre-computedmetadata managed by the jukebox provider (and accessible via the centralserver or the like), etc. In other cases, however, the karaoke jukeboxsystem may be able to implement algorithms to search for a melody lineagainst which the performance is to be gauged.

The karaoke jukebox's implementation of this dynamic melody creation,interpolation, or extraction, can be compared against the inbound audioto create informative and entertaining renderings on the displaysconnected to the karaoke jukebox system. A score can be associated tothe performance by comparing the performance to the actual or inferredmelody line and/or detected timing or syncopation to the originalmaterial for scoring on note accuracy, timing accuracy, and/or the like,e.g., resulting from the comparison of the karaoke performance againstthe performance popularized by the originating artist and saved in amemory for later use and/or consultation. These accuracy assessments cantake place in a regular sampling in certain instances, resulting in ascore for each sample and allowing the system to produce an aggregatescore depending on the policies in place such as, for example, favoringstrong beginning or endings, favoring entire song, discarding deviationsbeyond a threshold, weighting deviations differently, etc.

In certain exemplary embodiments, the supporting instrumentation (e.g.,the song data absent to vocal tracks including, for example, the rhythmsection, etc.) may be modified based on, for example, the calculatedquality of the performance as compared to the derived melody line. Forinstance, if a scoring system of the karaoke jukebox system determinesthat the performer is performing above a threshold, the karaoke jukeboxsystem may be made to generate additional audio signals to be layeredinto the performance audio (such as applause) and to display new video(e.g., cheering crowds, crowds waving lighters, etc.) and/or cues on thekaraoke jukebox video system.

Similarly, in addition or in the alternative, the performer's microphonevolume may be altered (potentially dynamically), e.g., based on thecalculated quality of the performance as compared to the derived melodyline. The scoring system may determine that one performer out of a groupof performers singing at the same or different times is scoring higherand thus “doing better” than others. For that singer a, dynamic melodycreation, interpolation, extraction arrangement of the jukebox, or thelike, may be configured or programmed to have the volume of audioincreased relative to the other performers. Similarly, poor performersmay have their volume reduced. Additionally, or alternatively, evenwithin a single song, the microphone volume may be increased relative tothe underlying song for a good performer, whereas the microphone volumemay be reduced the microphone volume may be for a poor performer and/orsupporting vocals may be added.

As alluded to above, then, in certain exemplary embodiments, a singer'sperformance may be based on the calculated quality of the performance ascompared to the derived melody line. By using the different scores ofperformers saved in memory, for example, the scoring system may be ableto rate the performance of a performer as an overall score to allow theperformer to be compared to other performers and performances of thatparticular performer or other performers. Similarly, scoring may bebased in part on a detection regarding the cadence of the song lyricsand a corresponding comparison to the beat of the song. A karaokejukebox may use algorithms related to beat detection to alter itslighting, as well as for cadence comparison related to perceivedconsonants to the song beat. Improved alignment and timing may be madeto result in a higher score. Scores in absolute terms and/or tending toreflect comparative performance, e.g., over time for a particularperformer, may be provided in certain exemplary embodiments.

Depending on the resulting beat detection and performance comparisonprovided by said above algorithm, it may be desirable to add supportingacoustics to the performance, for example, to add beat or rhythm backinginstrumentals to the performance. If a performer appears to be off-beat,it may be desirable to reduce the volume of that performer's microphone,slow down or speed up the song accordingly, and/or take otherameliorative actions to make the song sound better or at least “not asbad” as it otherwise might. Thus, certain exemplary embodiments supportalteration of the supporting instrumentation based on the calculatedquality of the performance as compared to the consonants timing to thebeat or the like, microphone volume based on the calculated quality ofthe performance as compared to the consonants timing to the beat o thelike, etc. The singer's performance may be rated based on a variety offactors as indicated above.

FIG. 9 is a flowchart showing an illustrative process for scoring akaraoke performance, in accordance with certain exemplary embodiments.Scoring metrics and/or baseline data is/are defined or calculated instep S902. Baseline data may correspond to, for example, the rhythm ofthe song or syncopated or otherwise punctuated portions of the song,notes, and/or the like. In step S904, the song is performed. Theperformance is compared to the baseline during and/or after theperformance in step S906. Feedback may be provided during and/or afterthe performance in step S908. The feedback may be encouraging ortaunting comments, instructions or other visual indications to singhigher or lower (e.g., using a pitch meter or the like), generatedapplause or cheers or the like, etc. Feedback may be producedautomatically (e.g., in the case of pitch meter or the like, cheers,etc.), based on patron-specified messages (e.g., sent via text, email,through a mobile application running on a mobile device of the patron,etc.), KJ provided messages, etc. A score may be calculated in stepS910, e.g., based in part on the scoring metrics. The scoring metricsmay, for instance, determine how many points are to be awarded forsinging a note within a specified range of an expected pitch, singing aword or series of words or beat-boxing or the like at appropriate orexpected times, manipulating the microphone or other props in anexpected way, etc. This score may be archived in step S912. In so doing,information regarding the performance (e.g., as shown and described inconnection with FIG. 5, for example) may be saved. Optionally, the songperformance may be saved and/or shared in step S914. In certainexemplary embodiments, a performer's scores may be tracked over timeand/or may be used as a baseline “handicap” for subsequent scoring, forexample.

The key that a performer is best suited to is rarely known for theaverage individual attempting karaoke. Performers therefore mayinadvertently find themselves attempting to sing a song that out oftheir vocal range, potentially presenting a greater challenge thanotherwise would be necessary or might be desirable (e.g., for anenjoyable experience). A key change algorithm in certain exemplaryembodiments therefore may change the key of the song by dynamicallytransposing it, or raising or lowering the music frequency, or evenauto-tuning the incoming audio from the performer's microphone. However,it may be possible for certain exemplary embodiments to recommend a bestkey for a performer to use and/or a best key for a performer to use on aparticular song, e.g., based on past performance and scores, historicalor predicted vocal ranges, etc.

It also would be advantageous for a performer to be able to determinetheir natural key. This may be possible by having the performer sing ashort scale or arpeggio following some prompting audio. Alternatively,or in addition, “corrections” for a performer may be made insubstantially real time, e.g., by having the person sing a short scaleor ratio or song lyric and displaying a graphic showing higher or lower,or just right. This may be performed as a part of a per-performancesinger calibration step or during karaoke mode in certain instances. Thekey determination algorithm may be able to guide a performer to his orher most natural key (e.g., by visually or otherwise informing theperformer how well the performer sings the short scale or audio segmentdescribed above, compared to a known or derived baseline) and, oncedetermined, suggest a difficulty rating for each song for thatperformer, e.g., based on how far away a given song is from the naturalkey, etc. For instance, songs that are within a whole step of a naturalkey may be rated as easy, songs that are within a major third may berated as medium difficulty, songs that are between a major third and amajor fifth away from a natural key may be rated as hard, and songsbeyond that may be rated as “very hard” or “expert.” Such rating may besaved in a memory and compared to the natural key of the performer,e.g., to generate a display list within which the difficulty level isindicated. It also may be able to inspect the number of determinedmelody line notes that are outside of the performer's range or expectedrange. The greater number of derived melody notes within the performersrange, the higher the confidence level would be that the song would beappropriate for the patron. A song with many notes outside theperformer's perceived range would be a more difficult song to perform.

Auto-tuning or auto-tune-like features also may be present on oraccessible via the karaoke system and selectively actuated withinpredetermined thresholds to compensate for deviations within certainamounts and/or to create interesting effects at the appropriate timesduring certain song performances.

FIG. 10 is a flowchart showing an illustrative process for adjustingaspects of a karaoke performance, in accordance with certain exemplaryembodiments. Similar to the description in FIG. 9, baseline data may bedefined and/or calculated in step S1002. Optionally, performer-specificadjustment settings may be retrieved (e.g., from a central server) instep S1004. The performer-specific settings may indicate, for example,that the user needs a particular average auto-tune adjustment whensinging a given song, that the volume should be increased or decreasedin some way, that distortions should be added, etc. In certain exemplaryembodiments, the performer-specific settings may be customized for aparticular song, venue, and/or the like. The song is performed in stepS1006. Similar to step S906 in FIG. 9, a comparison to the baseline datamay be made in step S1008. Settings may be adjusted based on deviations(e.g., within predetermined thresholds) from the baseline data. Forinstance, auto-tune settings may be adjusted, the song may be transposedor have its pitch altered, tempo may be increased or decreased, etc. Instep S1012 performer-based settings may be saved and/or modified basedon this performance. Similar to step S914 in FIG. 9, in step S1014, thesong may be saved and/or shared.

If a performer has been identified to the system and the system hasdetermined a most comfortable key (e.g., through an advising proceduresuch as that described above, the performer submitting a mostcomfortable key, an analysis of past performances, etc.), the system maybe configured to suggest the key that a song should be performed inand/or that is most suitable for the performer and yet stillrecognizable to the audience. This may be accomplished, for example, bycomparing the song, the metadata identifying when singing is takingplace, and the perceived or derived melody. Song suggestions also may begenerated and/or particular songs ranked based on this data in certainexemplary embodiments. Rather than the performer selecting a specificsong the system may in certain instance provide a game allowing otherperformers to issue a challenge, e.g., by selecting a song to be sung bya performer who has already agreed to participate in the game andoptionally sending a message to that performer, displaying a message ona shared or centralized display, etc. In one example scenario, the gameprogram may offer the possibility to define one or several teams withthe name or other indicia of the singers. There could be, for example,multiple (e.g., two or more) teams of one or more (e.g., three) singers.The game program may allow each team may take turns selecting a song forone or more of the other teams' singers. With little preparation, thechallenged singers may be asked to perform the song chosen by theopponents. The audience may rate the song performance through a scoringsystem, simple applause that could be detected by the microphone, bysending text, email, or other messages, etc., and the game program maygenerate a ranking by using such information. Rankings couldadditionally or alternatively be based on the more objective techniquesdescribed above. Different weights could be assigned to objective(system-determined) and subjective (audience-provided) feedback todetermine an overall score. Indeed, objectively “bad” performancesoftentimes are enjoyable to audience members, and good “stage presence”can sometimes make up for some objective deficiencies in theperformance. The tables could then be turned, and the challenged singersmay be able to select a song for their opponents in an example karaokejukebox operating mode.

In another example variation, the system may be set up to select songsat random but from one or more specific categories, genres, etc. (e.g.,from country classics). In this mode, patrons may be asked to sign up toparticipate in the “country classics challenge” and may be asked toperform the songs selected by the system based on criteria establishedat the beginning of the contest.

In still another example variation, possible songs may be presented tothe audience for the next performer. Based on voting from mobile phones,applause judged by the performer or the system, etc., one of thepossible next songs may be selected. This sort of “karaoke roulette” mayallow for a tournament orientation, a game that allows an evening orsegment of an evening to take place, etc. The scoring may be the same asor different from that described above.

It will be appreciated that these and/or other “variations” may beprovided in various combinations and sub-combinations in differentexemplary embodiments to provide enjoyable karaoke experiences. Thus, itwill be appreciated that these and/or other “variations” may beavailable on a single karaoke jukebox device, e.g., in differentoperating modes selectable by a KJ, venue staff, or other persons.

The karaoke jukebox system are provided with a connection arrangementthat may support connections to smart phones or portable devices in amanner that allows them to enter the karaoke jukebox environment butcontinues to respect and manage the licensed content being presented onthe karaoke jukebox. The connections from the smart phones or portabledevices may take place directly from the portable device to a local areawireless system or near field communication system within the venue,through Bluetooth connections, over a wide area network connecting thesmart phone to the karaoke jukebox system server infrastructure, or insome other way.

By virtue of commands and exchange of messages, the serverinfrastructure may communicate to the karaoke jukebox system commandsfor changing behavior. These commands may include, for example:

-   -   A request for a music or karaoke catalog;    -   A request for lyrics for a song within the catalog;    -   A submission of user credentials to log in to the karaoke        jukebox system;    -   A command to check in or initiate a session with respect to a        particular venue;    -   A submission of a song performance request;    -   A withdrawal of the song performance request;    -   A request to defer or accelerate a performance request;    -   A comment or vote or request for information about the current        performance;    -   A request for the pending queue of performances;    -   A submission from the mobile device to the karaoke jukebox of a        photo taken of a performer;    -   A submission from mobile device to the karaoke jukebox of a        picture or video taken of a performer's performance;    -   A request from the mobile device to the karaoke jukebox and the        karaoke jukebox server infrastructure to establish a venue time        allowing for synchronization of the devices and the synchronous        presentation of lyrics;    -   Information concerning performance and submission of other vote,        a survey response, responses related input;    -   Other features, as appropriate.

In certain exemplary embodiments, a mobile device may interact with thekaraoke jukebox system to search for content using suitable criteriasuch as, for example, song name, artist, album, genre, theme,recommendations, collections, etc.

In certain exemplary embodiments, a mobile device may interact with thekaraoke jukebox system to follow synchronized lyrics being presented onthe karaoke jukebox device and/or secondary displays, directly on amobile device.

In certain exemplary embodiments, a mobile device may interact with thekaraoke jukebox system to select a song from the catalog and to submitthat song name and a performance name for addition to the performancequeue.

In certain exemplary embodiments, the karaoke jukebox system is providedwith an arrangement enabling a mobile device to interact with thejukebox system by delivering comment messages to comment on aperformance from the mobile application such as, for example, sendingencouragements to enthusiastically support the performer, to remainneutral, to comment on how good or how poor the performance is, etc. Incertain exemplary embodiments, the messages sent by the mobile devicemay be used to vote up or down, or like or dislike a performance, e.g.,by allotting a timeframe to send messages considered as votes, byinserting in the message a flag identifying the message as a vote, etc.More numerical voting or scoring also may be possible. The votes and/orscoring features may be tabulated and displayed via a display in thekaraoke jukebox system.

In certain exemplary embodiments, a mobile device may interact with thekaraoke jukebox system to record a performance using the video camera inthe mobile device. This video stream may be sent to the karaoke jukeboxsystem, and/or the server for merging with the high quality audioprocessed through the microphone(s) connected to the karaoke jukeboxsystem, e.g., to create performance video file for later access.

Thus, it may be possible to use a mobile application on the mobiledevice to record video of the performer's performance of a song. Thejukebox system, server, or mobile device may include an arrangement toappropriately synchronize that video with the audio captured by thekaraoke jukebox system. In addition, it may be desirable to have some,all, or none of the ambient noise of the crowd and the venue to be addedto the composite performance audio. Accordingly, the audio and videofiles captured by the mobile device may be transmitted through the localwireless within the location, over a wide area network through thekaraoke jukebox server infrastructure, or via some other means, to thekaraoke jukebox system. At that time either, within the karaoke jukeboxsystem or within the karaoke jukebox server infrastructure, for example,the original song music, the recorded audio from the performer orperformers, any real-time alteration such as reverb, the video from themobile device and, optionally the audience audio from the mobile device,may be integrated into a complete video performance package. This videoperformance package may be a video file on its own, a series of filesthat would enable the creation of a video file based on mix input rulesgoverning the relative volumes of all audio data and the resultingquality metrics of the output audio video file, etc. Synchronization maymake this combination possible. Similar to the description above, audioand/or video content may be pre-pended or appended.

In certain exemplary embodiments, a mobile device may interact with thekaraoke jukebox system to purchase a rehearsal package for use at homeor at a location other than a venue, with the package optionallyincluding a fixed number of recordings. On the mobile device, it may bedesirable to select a song and, if required, purchase the rights tousing that song and lyric data to rehearse for a future performance.This rehearsal package may allow the mobile user to purchase or to havetemporary access to a version of the song lyric data playable within thekaraoke mobile device one or more times, e.g., up to a limit identifiedwithin the package. This rehearsal package may (either for free or atsome charge) enable the user to practice singing on the mobile devicefor a number of hours or days, a finite number of performances, or in anunlimited manner. In certain example implementations, after this timehas elapsed, the number of performances has been met, etc., the musicand lyrics may not be made available as part of the rehearsal package.It also may be possible to purchase special rehearsal packages that haveno limit or much larger limits on rehearsal access to ration orrehearsal number of attempts in different implementations. In certainexemplary embodiments, the rehearsal application may be available forfree or a one-time cost, whereas particular rehearsal packages withparticular songs may be provided for free or for some amount of money.

FIG. 11 is a flowchart showing an illustrative process for using arehearsal package in accordance with certain exemplary embodiments. Instep S1102, a rehearsal package is downloaded (e.g., to the device onwhich the package is to be run). A rehearsal package may include one ormore songs for practice purposes. In certain exemplary embodiments, arehearsal package may be matched with one or more songs, e.g., so that auser may download a rehearsal package/song combination. In otherexemplary embodiments, a generic rehearsal package may be provided withsongs optionally being separately downloadable. The performer may singfor the rehearsal package as practice in step S1104. Similar to asdescribed above, a comparison may be made to baseline data during and/orafter the practice performance in step S1106. Baseline data may becalculated in substantially real time, preprogrammed as a part of therehearsal package, etc. Feedback optionally may be provided in stepS1108. A rehearsal score may be calculated in step S1110. The rehearsaldata optionally may be archived (e.g., to the device on which thepackage is running, a network location such as, for example, a centralserver, etc.) in step S1112. This optional archiving may allow aperformer to track his/her performances and possible improvements overtime. It also may be used to enable adjustments to be made in a livekaraoke jukebox environment, e.g., such that expected auto-tune, volume,tempo, pitch adjustment, and/or other settings may be altered to accountfor expected deviations from baseline data. In the event that arehearsal package and/or song has limited usage, the same may beselectively disabled (e.g., after a predetermined number of uses, aftera certain time has elapsed, etc.), in step S1114. In certain exemplaryembodiments, the rehearsal package may include commercial songs, scales,simple compositions, public domain songs, and/or the like.

Performance and/or grading techniques such as those described above maybe possible via a rehearsal module running on a mobile device equippedwith a suitable mobile karaoke jukebox application. For instance, it maybe possible in certain exemplary embodiments to use a rehearsal packagevia the mobile device to detect the dominant melody line within a songand to allow the performer to be measured against this melody line. Forinstance, when using a rehearsal package on the karaoke mobile device,it may be possible to offer the ability for the performer to be measuredagainst this melody line and observe visual and/or audio feedbackmeters, gauges, or indicators. This may involve the mobile applicationdetecting the dominant melody line, making use of a metadata fileincluding the melody line, etc., and comparing the input audio to theexpected melody.

It may be possible in certain exemplary embodiments to use a rehearsalpackage via the mobile device to alter the supporting instrumentationbased on the calculated quality of the performance as compared to thederived melody line. For example, additional beat backing instrumentalscould be added as encouragement, or additional voice support may beadded for “bad” performances.

It may be possible in certain exemplary embodiments to use a rehearsalpackage via the mobile device to alter the performer's microphonevolume, e.g., based on the calculated quality of the performance ascompared to the derived melody line.

It may be possible in certain exemplary embodiments to use a rehearsalpackage via the mobile device to rate the performer's performance basedon the calculated quality of the performance as compared to the derivedmelody line.

It may be possible in certain exemplary embodiments to use a rehearsalpackage via the mobile device to detect the rhythm and beat within asong and to allow the performer to be measured by the comparison ofconsonants timing to the beat. As in the karaoke jukebox system, it alsomay be desirable within the karaoke mobile system that the musicobtained from the karaoke jukebox could be analyzed for beat detection.This beat detection may be used to detect the rhythm and intonation ofconsonants within the performance and provide a comparison to the musicbeing rehearsed. Alternatively, or in addition, metadata may be providedto aid with or reduce the need for sophisticated detection techniques.

It may be possible in certain exemplary embodiments to use a rehearsalpackage via the mobile device to alter the supporting instrumentationbased on the calculated quality of the performance as compared to theconsonants timing to the beat. Depending on the score of thiscomparison, additional backing instrumentation could be added, removed,etc.

It may be possible in certain exemplary embodiments to use a rehearsalpackage via the mobile device to alter the performer's microphone volumebased on the calculated quality of the performance as compared to theconsonants timing to the beat.

It may be possible in certain exemplary embodiments to use a rehearsalpackage via the mobile device to rate the performer's performance basedon the calculated quality of the performance as compared to theconsonants timing to the beat.

Performers may use their mobile devices to identify themselves and viewpersonal, competitive, historical, and/or other performance data. Forinstance, previous performance data for poor performers who haveidentified themselves may be maintained on the karaoke jukebox serverinfrastructure. This content may be available through controlled playersystems so as to respect the original rights holders' work. The karaokejukebox mobile application may connect to the karaoke jukebox serverinfrastructure for the purpose of obtaining previous performances andperformance data for the individual who has submitted the appropriatecredentials. In other words, to view a video, a mobile device user mayhave to access content from a secure site or portal through whichroyalty and/or other accounting metrics may be maintained. This approachmay allow the karaoke mobile device to play contents from the karaokejukebox server infrastructure on the karaoke mobile device in acontrolled manner that also respects appropriate copyright laws and/orother relevant agreements. It also may be possible for karaoke jukeboxpatrons to lend or provide temporary access to media related to theirperformances, which may be stored on the karaoke jukebox serverinfrastructure. That media may, for example, be viewed using controlledkaraoke jukebox player systems that continue to respect the rights ofthe original song rights holders and also the rights of the performer.

An identified performer may be able to view previous performances via amobile device. For instance, on the karaoke mobile device, once anindividual has submitted the appropriate credentials, the individual maybe able to view their own content (performances and performance data),as well as content for those performers to which they have been providedtemporary or permanent access.

An identified performer may be able to share a performance with othersthrough a submission to a social media service through a mobile device.For instance, it may be possible for performers to submit a performance,a performance snippet, or performance data or a combination thereof, toa social media site, e.g., once they have submitted their credentialsfor a social media service. In certain implementations, such submissionsmay be automated (e.g., for a venue's social network presence, forcertain registered users who have configured their applicationsappropriately, etc.). For this media to play in the social media site,the social media site may have to support a karaoke jukebox system mediaplayer that that is configured to respect all of the rights of thoseconcerned (e.g., by providing limited access, royalty accountingfunctions, etc.).

Conventional jukebox environments and karaoke environments differ in thesense that, for karaoke environments, there is the concept of aperformance soundstage. The karaoke experience may be improved by theirbeing stronger sound around the performance and less sound when far fromthe performance.

In addition, or in the alternative, a performer may benefit from amonitor, e.g., so that the performer can perhaps more easily hear themusic, voice, etc., and make the appropriate adjustments. Monitors maybe provided on the floor in front of the performer and facing up at anangle. However, this arrangement can be problematic within some normalbars and restaurants, as the performance stage often serves“double-duty” as the dance floor during jukebox periods. It may be moreconvenient to have a portable and optionally wireless performer monitorthat could connect to the karaoke jukebox when required in certainexample scenarios. In certain exemplary embodiments, a performer may usewireless headphones connected to the karaoke jukebox as a monitor. Inother exemplary embodiments, a mobile application running on a portabledevice of the performer may be used to playback the background and/orvocal audio, thereby functioning as a monitor. The karaoke monitor mayin certain implementations make this connection to the karaoke jukeboxwirelessly and without any perceived latency. This could be accomplishedthrough conventional wireless data technology, through analog RFcommunications that could be less subject to interference from otherequipment within the venue, and/or other suitable techniques. This sortof arrangement may help avoid the requirement for a wire running acrossa potentially high-traffic area. It also may be desirable to have thismonitor speaker be battery operated, thereby helping to reduce the needfor a power cord. This monitor system could be moved to a safe locationwhere it could be recharged during the day and then put into positiontemporarily during karaoke performances. The karaoke jukebox system maytreat this as an additional zone and allowed the performer or the KJ toadjust relative volume for the performers.

Certain exemplary embodiments relate to karaoke video and lightingaccessories. As in conventional jukeboxes, karaoke jukeboxes may havethe ability to control outbound lighting via a DMX output stream, aserial stream of data indicating light control, or some other means. Thekaraoke jukebox also may be able to control performer spotlightsinstalled in the venue. These venue spotlights may be aimed at theperformance area and may alter color and intensity based on the datastream transmitted from the jukebox, e.g., in time to the music and/orin response to metadata associated with the song being performed,scoring, audience reactions, KJ cues, etc. In addition, or in thealternative, it may be possible, under control of the karaoke jukeboxsystem, to move the spotlights according to predetermined animationssuch as, for example, searchlight and audience highlight, as well as avariety of other video effects with the lights moving about. The lightsmay return to the stage based on commands from the karaoke jukebox,after a predefined animation has run, upon KJ cues, etc.

The pan-tilt-zoom (PTZ) capability of these spotlights may in certainexemplary embodiments also be applied to a video camera in certainexemplary embodiments. A video camera may, for example, respond to pan,tilt, and zoom controls from an operator using either a remote control,the karaoke mobile device specially equipped with the remote control, anautomated device tracking the performer, etc. Performer tracking couldtake place from the performer positioning him or herself within a targetthat is displayed on the second screen, the karaoke jukebox, a screenvisible on the audio monitor, or elsewhere. Once positioned inside thescreen, and with the song beginning, the karaoke jukebox system maytransmit pan-tilt-zoom commands as appropriate to the camera, e.g.,based on face, motion, and/or other tracking of the performer.

This PTZ camera and spotlight capability also may be controlled by acamera, trained on the performer, or elsewhere. However, in certainexemplary embodiments, it may respond to infrared light or other signalsbeing emitted by the performer's microphone, e.g., for trackingpurposes. A periodic confirmation of the face location of the performerholding the microphone may allow the camera to self-correct throughoutthe performance in certain example instances.

The performance monitor may include both audio speakers and a videoscreen for prompting the performer in certain exemplary embodiments.This video screen may perform a face tracking alignment and show thesinger's performance superimposed with the lyrics or, alternatively orin addition, could be simply the lyrics or the performance.

The karaoke jukebox microphone system may include a mechanism foranimating in visible light such as, for example, infrared or a spatial(e.g., geo) positioning signal, potentially allowing the camera and/orspotlight within the venue to illuminate and record video of theperformance. The karaoke jukebox microphone system may have the abilitythrough either a gesture or a button to restart a song from the karaokesystem in certain example implementations. The karaoke jukeboxmicrophone system may have the ability either through a gesture or abutton to allow the performer to enhance voice performance (e.g., viaauto-tuning features). The gesture could allow the second screen or themonitor screen to display options for the performance such as, forexample, change key, add reverb, auto-tune, etc.

The karaoke jukebox system may include a server infrastructure thatallows patrons using their mobile devices, home computers, or otherdevices, to access and interact with (e.g., through a browser) thekaraoke jukebox environment. This interaction may take place in a mattersuch that the media presented is secure and respects the song rightsholders' rights. Thus, the karaoke jukebox infrastructure may allowperformers to identify themselves through credentials to gain access tothe system or at least access to protected media content, performancedata, and/or the like. Identified performers with suitable rights may beable to view previous performances, a record of previous performances,and/or the like, through the karaoke jukebox infrastructure.

An identified user could, subject to fees and/or the limits imposed bythe rights holder, share access to performance data or performances withother identified users. In addition, or in the alternative, anidentified user could, using social media credentials, post access toperformance data, performances, or portions thereof, on a correspondingsocial media site. If the site supports a karaoke jukebox infrastructuremedia player, for example, it may allow for controlled access to otherusers already qualifying for access based on authorization by theidentified user. In certain exemplary embodiments, generated content maybe made available in a proprietary format that is only accessible via ajukebox infrastructure media player. For instance, the proprietaryformat may include digital rights management (DRM) features, watermarks,and/or the like, and may thus facilitate rights-tracking and royaltyaccounting. For performances where unlimited rights have been acquiredor where the rights are not required, it may be possible to postperformance data or performances to fully public sites. It also may beadvantageous for both the rights holders and further performers to beable to post snippets of performance data or performances to socialmedia sites and to sites used to promote the karaoke experience at thevenue or on behalf of the karaoke network or a partner of the karaokenetwork. These snippets need not necessarily contain the entireperformance, but instead may provide an opportunity to share a portionof the experience and encourage further investigations. For example,snippets may effectively serve as “teasers,” incentivizing a person topurchase a performance, e.g., as a memento of an enjoyable outing.

An identified user may be able to purchase or request use of a rehearsalpackage for use out of the venue. As indicated above, this rehearsalpackage may include a duration of time for which the user is able tohave access to the song(s) and lyric data for the purpose of practicing,a finite number of performances where the user would have access to themusic and the lyric data, etc. In addition a rehearsal package mayinclude guidance instructions or anecdotes surrounding the performanceof a particular song.

It may be helpful for the performer to view the quality of hisperformance as established by comparing the voice to the derived melodyline or a melody metadata for that song. This could be graphically oracoustically presented to the performer to encourage and adjust his orher performance. Based on the scoring of the performer's rehearsal, thesupporting instrumentation could be altered to provide encouragement.Similarly, using a rehearsal package, the performer's microphone volumemay be altered based on the calculated quality of the performance ascompared to the derived melody line. The performance ultimately could berated, e.g., based on the calculated quality of the performance ascompared to the derived melody line, beat of song and the lyricsmetadata to provide feedback as to the timing of the rehearsal, etc.Based on the scoring of the performer's rehearsal of the song timing andrhythm, the supporting instrumentation may be altered to encourage therehearsal. In addition, or in the alternative, the rehearsal package mayinclude audio snippets of encouragement from performers or musicexperts.

The performance packages discussed herein may be provided as standalonecomponents, modules, or arrangements, executable on a computer deviceincluding at least one processor and memory. Such components, modules,or arrangements may, for example, be configured to execute process stepscorresponding to the flowcharts shown and described herein. Theinformation obtained via rehearsal packages may be stored and uploadedto the karaoke jukebox server, e.g., for future consultation, e.g., inthe event that the singer ever attempts to perform a song. Based onperformance data from the rehearsal package, values such as degree ofauto-tuning, microphone volume, background music volume, etc., may beread and set for the venue.

The following are illustrative use cases for an improved karaoke jukeboxsystem in accordance with certain exemplary embodiments.

FIGS. 12a-12f show a first use case pertaining to first time songqueuing in accordance with certain exemplary embodiments. A patronbrowses on a display for a song, possibly using karaoke specificbrowsing criteria (FIG. 12a ). The browsing may take place via thekaraoke jukebox device, a mobile device in the venue, etc. A preview ofthe lyrics may be provided, and the song selected on the display may beadded to the queue (FIG. 12b ). A photo of the patron may be taken (FIG.12c ), e.g., for the queue and/or performance display. The patron mayopt-in for SMS or other notification (in which case the user may need toenter a telephone number if the user is not already a recognized user ofthe karaoke jukebox system or has not provided such data through acredentialed social media service into which the patron has logged in)(FIG. 12d ). The patron may be prompted to sign up for myTouchTunes. Thesong may be paid for, and a “how it works” video may be displayed (FIG.12e ). Some or all of the queue may be displayed for the user,optionally with the photos or other indicators of the soon-to-beperforming patrons (FIG. 12f ).

FIGS. 13a-13f show a second use case pertaining to smart songsuggestions in accordance with certain exemplary embodiments. A user mayview the myTouchTunes karaoke mobile application suggestion screen andbe prompted to take a range or other test (FIG. 13a ). The user may thentake the test to determine the “best” or at least recommended songs tobe sung (FIG. 13b ). The user may view the results of the range test andthe song suggestions (FIG. 13c ). These suggestions may be viewed basedon the patron's interested, and the patron may be prompted to scan thekaraoke library (FIG. 13d ). The song results from the library scan maybe viewed (FIG. 13e ), and the song may be added to the queue. Some orall of the queue may be displayed for the user, optionally with thephotos or other indicators of the soon-to-be performing patrons (FIG.13f ).

FIGS. 14a-14f show a third use case pertaining to performing a song inaccordance with certain exemplary embodiments. The patron may receive anotification (e.g., an SMS, email, or other notification) that it isabout to be that patron's turn to perform (FIG. 14a ). The patron maystep onto the staging area and obtain the microphone (e.g., from themicrophone stand) (FIG. 14b ). Pitch help optionally may be selected(e.g., via a button on the microphone) (FIG. 14c ). The patron may beinstructed to press the play button (e.g., on the microphone) when thepatron is ready to perform (FIG. 14d ). When the play button isdepressed, the microphone may be activated and the music may be started(FIG. 14e ). The lyrics and/or melody may be displayed to help theperformer complete the performance aspect of the karaoke experience(FIG. 140. It is noted that settings may be downloaded and put intoplace if the user is a recognized user and has previously set suchsettings (e.g., regarding pitch help, transposing, volume, etc.), hascompleted one or more rehearsal modules, has a karaoke history that canbe read and summarized, etc.

The patron looks at the lyrics screen and is able to see feedback fromthe crowd. Prompts for actions to be undertaken during a performance maybe provided, e.g., as shown in FIGS. 15a-15d . For instance, in asixteen bar break, an indication for motion control is provided. Theindications may be intended to correspond with the beat, and the patronmay see the motion and/or feedback on the screen. When the song is over,the crowd reaction may be shown on the feedback screen. In certainexemplary embodiments, the microphone may be provided with one or moregyroscopes, accelerometers (linear or non-linear), etc., for determiningor inferring the position, movement, and/or orientation thereof. Acomparison between movements signaled by the display and the signaltransmitted to or otherwise obtained via the jukebox or server andcorresponding to actual movements may be calculated, and the performer'sscore may be based in part on this tracking in certain exemplaryembodiments. These and/or other motion sensors and/or locators may helpdetermine or infer the position of the microphone and thus theperformer, enabling a tracking system for camera and/or lightingarrangements in connection with the karaoke jukebox system to orientatethe camera and/or lighting towards the performer at all or selectedtimes. Gyroscopes, accelerometers, and/or the like, provided to themicrophone, may be used to track or infer movement in certain exemplaryembodiments. The camera and/or lighting may be integral with or separatefrom (but in operable connection with) the karaoke jukebox system incertain exemplary embodiments.

FIGS. 16a-16f show a fourth use case pertaining to audience engagementin accordance with certain exemplary embodiments. For instance, triviamay be shown on a display (FIG. 16a ). A user may submit an answer to amultiple choice or other question via SMS, email, a dedicatedapplication accessible on a mobile device, etc. (FIG. 16b ). Patrons mayreceive feedback if they have won a prize (e.g., credits) and may beprompted to download the myTouchTunes application (FIG. 16c ). The usermay then download myTouchTunes (FIG. 16d ), register for an account(FIG. 16e ), and use the credits won from the trivia contest (FIG. 160.Of course, it will be appreciated that other audience engagementfeatures may be offered including, for example, rating a singer'sperformance, voting for a next song to be performed or for a patron toperform, etc.

FIGS. 17a-17f show a fifth use case pertaining to socializing thekaraoke experience in accordance with certain exemplary embodiments.When queuing a song, a patron may opt to have a video recording made ofthe performance. The patron may also be asked to sign up for amyTouchTunes account if the patron is not already a recognized user ofmyTouchTunes. A video of the performance may be captured and saved tomyTouchTunes. The patron may later receive an e-mail with a link to thevideo of the performance. After following the link, the patron may loginto myTouchTunes to watch the video of performance. Some or all of thevideo of the performance may be shared via Twitter, Facebook, and/orother social networks.

In certain exemplary embodiments, the video that is captured mayincorporate video content captured by a camera integral with the karaokejukebox system, external cameras provided in the location, and/or videocaptured by one or more portable devices (e.g., smart phones or thelike) of one or more patrons in the establishment. Because devicesconnected to the karaoke jukebox system may have a synchronized timebase, the disparate sources may be spliced together as the performanceis taking place or at a later time. For instance, it may be possible fora KJ to instruct one or more displays in the venue to receive a videosignal from a particular device. Much like a director, the KJ may switchthe effective input video source. A patron may also be able to do thisat a later time, e.g., to create a custom movie of the performance. Forinstance, video from plural devices may be submitted (automatically orupon a user request) to the central audiovisual network server andassociated with a particular performance date/time and/or performer. Theperformer or others may search through a catalog of user-generatedcontent to make their own movies. High-quality audio recorded by thekaraoke jukebox microphone may be added as the audio track to the video.As above, this may be facilitated by virtue of the time synchronizationfeatures of certain exemplary embodiments. In certain exemplaryembodiments, a composite video may be automatically generated. Forinstance, the video may randomly select different video segments or mixin the karaoke jukebox video content with user content on a random,pseudo-random, or non-random basis. The other patrons' cameras mayprovide different angles of the performance. Thus, in certain exampleinstances, regardless of whether the video content is user-generated orautomatically generated, the other views may be selectivelyincorporated, e.g., based on the performer's movements. The performer'smovements may be tracked by the karaoke jukebox, the position-indicatingor -inferring devices (e.g., trackers, accelerometers, gyros, etc.)incorporated into the microphone, etc. Based on this data, tracking dataassociated with the devices, facial or image recognition performed onthe videos, and/or the like, certain videos may be selected for merginginto a common video file, e.g., with the high-quality captured audio.

FIGS. 18a-18f show a sixth use case pertaining to performer engagementin accordance with certain exemplary embodiments. The patron firstsearches for a song to be performed, e.g., by a friend. The song may beselected because it is expected to sound entertaining, funny,particularly good or bad, etc. The patron may select a friend whoalready uses myTouchTunes. Alternatively, a user may enter an emailaddress to invite a friend to join myTouchTunes and/or participate inthe karaoke experience. The friend may receive a notification that a“dare” to perform a song has been received and may decide whetheraccepts the dare. The friend may perform the song, possibly earning thefriend a reward (e.g., unlocking a “dare badge”), earning a “coin” orcredit or token for each person checked-in at the site, and progress ofthe contest may be reflected on a display. The dare may be marked ascomplete, and the sender may be notified that dare has been completed.Of course, it will be appreciated that there are other ways forencouraging performer engagement, e.g., as between two or moreindividuals or teams of individuals, and that this is only one exampleof how challenges may be issued and completions of challenges rewarded.If a dare is accepted, the song may be added to the karaoke queue,together with an indication of the dared person (the person to performthe song) and/or the person who initiated the dare.

FIGS. 19a-19f show a seventh use case pertaining to performer engagementin accordance with certain exemplary embodiments. A venue manager mayuse the karaoke jukebox to configure the venue location. The venue maybe shown on karaoke venue map on myTouchTunes, e.g., with informationsuch as its name, address, themes, etc. Karaoke music preferences alsomay be configured, e.g., to give priority to certain genres, determineswhether karaoke performances are pay-per-play performances, the cost ofeach performance, etc. The karaoke jukebox may prioritize the specifiedgenres in user interface elements displayed to patrons interacting withthe karaoke jukebox or a mobile device checked in to the location.Details regarding karaoke availability and lists of special eventstaking place at the venue also may be specified by authorized personnel.Similarly, karaoke nights and events from some or all connected venuesmay be listed on the myTouchTunes calendar. In some cases, only thoselocations that a patron has subscribed to or otherwise expressedinterest in may be displayed on the calendar. In this regard, in certainexemplary embodiments, a module running on the jukebox and/or havingcontrol of the jukebox may enable an authorized user to provide suchsettings.

Photo booths are known in the art. However, the inventors of the instantapplication have realized it is possible to build on the familiar fun ofthe traditional photo booth through modern technology to create a nextgeneration experience. For instance, rather than providing a rathersterile environment in which pictures can only be taken at fixedintervals, certain exemplary embodiments relate to the incorporation ofphoto booth like activities into a jukebox and/or karaoke jukebox. Incertain of such exemplary embodiments, a series of digital photographsmay be taken in succession (e.g., 12 photos in some number of seconds).In certain of such exemplary embodiments, the flash color may beoptimized or improved for the environment through the use of LEDs orother lights disposed on the jukebox (e.g., by having the cameradetermine the lighting and then calculating the amount of offset for thelighting features, and adjusting the flash when taking the picture).Digital filters may help improve the quality of the picture and/orenable a user to express creativity. For instance, music themed filters,backgrounds, or the like may be added to a picture along with, or ratherthan, frames that may be music, venue, or otherwise themed. Drawingtools may enable users to make further modifications to captured images.Digital “proof sheets” may give users a potentially greater control oftheir photos and enable users to pick their favorites. Because photosare taken digitally, they may be delivered to a user or users through adigital channel such as, for example, email, posting to a server orsocial media site, etc. Captured and optionally subsequently modifiedimages may be incorporated into music videos, karaoke performances,attract loops, uploaded to social media sites for the venue and/oruser(s) whose picture(s) are taken, and/or the like.

The following description provides an example use case for a photo boothjukebox in accordance with certain exemplary embodiments. An attractloop for the photo booth may include previously taken and/or cannedphotos. From a “home screen,” a user may opt to switch to jukebox mode(e.g., to access jukebox related features), a photo booth mode, or avideo mode. When the user has selected the photo booth mode, the usermay have the option to take a test picture. Test pictures may be used tohelp users orient themselves in front of the camera, demonstrate howmuch of the picture will be cropped out, etc. Before taking a live shot,a user may be prompted to provide advance payment and/or accept theterms and conditions of use.

When the photo booth is ready to take a picture, a countdown may bedisplayed on the jukebox or related display, e.g., so that the person(s)being photographed can compose himself/herself/themselves appropriately.FIG. 20 shows an example countdown screenshot in accordance with certainexemplary embodiments. The areas that will be cropped from the image maybe indicated, e.g., as being grayed out compared to the main image area.

One or more photos may be taken. The photos may be taken each time auser actuates a button or the like (optionally followed by a countdown),in a fairly rapid photo burst manner, and/or the like. For instance,FIG. 21 shows an example photo burst screenshot in accordance withcertain exemplary embodiments. A current picture is displayed on thejukebox in a main display area. A timeline (shown above the main area inthis example) may indicate how many pictures have been taken whileproviding a small representation of each, while also showing how manymore pictures may be taken. The currently displayed picture may behighlighted. An ancillary display such as the LED array above the mainscreen may similarly show the progress of the photo burst.

An electronic or digital “proof sheet” may be displayed, an example ofwhich is shown in FIG. 22. Twelve pictures are shown in this example, asthat is how many images were captured during the photo burst. However,it will be appreciated that more or fewer images may be taken indifferent example scenarios. In situations where more images aredisplayed than are to be printed, saved, or otherwise manipulated, auser may select some proper subset of the images (e.g., four of twelveimages, etc.).

Various filters may be applied and/or elements added to some or all ofthe selected images. For example, a “rock star filter” may add multiplespotlights of different colors, while adding lens flares and/or theappearance of fog to create a “rock star like” atmosphere for thepicture. The images may be converted to black and white or sepia tone,softened, have their corners faded out or otherwise distorted to givethe appearance of a vintage or Technicolor image, etc. Blurring,shading, sharpening, red eye reduction, lens flares, etc., may be added.Images may have their color levels, brightness, contrast, etc.,adjusted. Frames may include, for example, vintage or rounded frames,themed frames (e.g., as shown in FIG. 23); frames for a particularsponsor (e.g., advertiser) or the venue; etc. In certain exemplaryembodiments, raw image data may be uploaded to a remote location and maybe subsequently manipulated in these and/or other ways, e.g., via aweb-based interface accessible via a mobile application, a remotecomputing device running a browser, and/or the like.

A user may select a target output device or location for the image. Forinstance, a user may opt to print the picture(s) to a printer integralwith or otherwise connected to the photo booth jukebox, send a digitalcopy via email or MMS message, post the picture to a particular socialnetworking site, etc. The photo booth jukebox may have suitable networkand/or telephony connections (potentially through optional servers orgateways) for accomplishing the digital transmission of the image(s). Auser may purchase additional copies for print or for digitaltransmission. Digital transmitted images may have copy protection,digital watermarks, etc., that may help guard against unauthorizedreproduction. In some scenarios, a user may pay a premium for anon-protected image. In cases where an image is to be uploaded to asocial media site on behalf of the user, a registered user's profile maybe queried to obtain the relevant username and password or othercredentialing information to allow logging in and posting to the site.If such information has not been provided, or if the user is not arecognized registered user, the photo booth jukebox may prompt the userto enter such information.

When printing and/or digital transmission is complete, the user may beprompted to return to the proof sheet, start a new photo session, returnto jukebox mode, etc. The attract loop may be updated to include therecently captured image in certain example instances (e.g., in the eventthat the user does not “opt out” of such inclusion).

As can be appreciated from the above, technology can be leveraged toimprove conventional photo booth experiences, while also tying them intothe jukebox and venue environment. For instance, the photo booth jukeboxmay become a “photo director,” instructing users to “strike a pose.”Participants may respond to suggestions about expressions to make (“Showme scared”), iconic poses (“Now Vogue!”), etc. Such pictures may beprinted, digitally transmitted, uploaded to a social networking site,etc.

In another example mode, users may sign up for a “night unfolding,”“scavenger hunt,” or “challenge” mode. Throughout a predefined time, amobile application running on a mobile device of a user may prompt theuser to take pictures at various times, with various people, withcertain expressions/poses/items/etc., and/or the like. These photos maybe turned into a slide show, video, or the like, that can be digitallytransmitted. Prizes may be awarded for successful completion of achallenge. Contests also may be run, e.g., for costume parties, etc.,where user-based voting is possible.

Time limits may be imposed in certain cases, e.g., to help ensure thatthe jukebox is not used for excessive photo booth operations. Forinstance, a user may complete a photo booth experience within 1-10minutes, with a typical minimum time being about one and one-halfminutes, and a maximum time of seven minutes being set. If a jukebox isbusy or has not been used or the queue is running low, deactivation ofsome or all of the photo booth features may be triggered. Timers may bedisplayed when a predefined use time is coming to an end (e.g., 30seconds before a 7 minute period is about to elapse), etc. In somecases, if user chooses to take a test shot, the photo may remain on thescreen for a short time (e.g., 10 seconds) or until a begin or playbutton is pressed. A test shot may be deactivated after a short time(e.g., 2 minutes) after use, as well. Live preview functions may beprovided in certain exemplary embodiments. The live preview functionsmay display raw image data, which may be maintained for possible lateruse. Facial detection for focus and metering may be activated, e.g.,using known algorithms. Optimization filters may be run once photos aretaken, potentially including a skin smoothing function and creating anenhanced effect to separate foreground elements from backgroundelements. Users may have predefined times for completing differentsub-operations within the photo booth experience. For instance, the usermay have 1 minute to complete selections from the proof sheet, 3 minutesto modify photos, 2 minutes to print/transmit selections, etc. Thesetimers may restart if the user returns to the proof sheet or starts anew photo booth session. Of course, it will be appreciated that thesetime frames are provided by way of example, and that longer or shortertime limits may be imposed in some situations, whereas some situationsmay not include time limits at all. Users may be charged for variousfeatures in different embodiments. For instance, a base purchase priceof, for example, $5, may enable the user to take a photo burst, selectfour photos, and print them out. This price may be reduced if no printeris attached, if a network connection is not possible, etc. Textmessaging, emailing, uploading, extra prints, more manipulations, etc.,may cost a premium in certain scenarios. In certain scenarios, digitaltransmissions and/or uploads may be provided free of cost, or possiblyfree of cost if the user opts in to allowing the venue to use the imagesfor publicity and/or other purposes.

With the advent of real-time broadband connectivity, it is possible forpatrons to make use of music lists that they, or their friends, maintainon external data services (such as, for example, social networkingsites). These data services may also allow for patrons to post theircurrent activities or observations. The digital jukebox systems ofcertain exemplary embodiments may allow patrons to identify themselvesto the jukebox by submitting credentials to a jukebox individual accountor a social networking account. Once identified, the activities such asmusic selection, comments on music, social plans, collections of music,etc., can be shared through the social networks.

In creating an identity on a jukebox network, it would be desirable toenable the patron to submit an image to be associated with an account.Such an image may be referred to as an avatar of a patron. It would bedesirable to enable a patron to create an avatar either by a separatetransaction performed from a computer or mobile smart phone where aphotograph is submitted to the jukebox network, or directly through thejukebox itself.

This may be accomplished in certain exemplary situations by configuringthe jukebox with picture-taking capabilities, and by allowing a patronto associate this picture with the individual's account. These imagescould be representative of a single person, a group account representingall the staff at a particular location, a close-knit group of friendssharing an evening, a larger group, etc. Alternatively, or in addition,rather than a still frame avatar, certain exemplary embodiments enablepatrons to take short videos of themselves and use these videos asavatars, or mementos of the time spent at the location. Indeed, theseimages and/or videos, like activity and music sharing, may providevisual mementos of time spent together in the venue. This may provide amore enjoyable experience for individuals, enabling them to enjoy musicand have a photo or video record of the evening.

As jukeboxes become more sophisticated and migrate towards media centersand incorporate more media center capabilities, it would be desirable toprovide supplemental audio and microphone capabilities. Doing so incertain situations could allow individuals at the jukebox to interactwith a system or remote individual and be able to hear audio intendedjust for them and not for broadcast throughout the venue. In addition,or in the alternative, individuals could respond or submit audio thatwould be picked up by a microphone configured to favor local audiorather than the audio on the surroundings.

These microphones, which may be provided inside the jukebox, as wirelessperipherals to the jukebox, etc., may allow patrons in certain exemplaryinstances to add audio clips to their avatars (e.g., still photo orvideo avatars) that could be experienced through social mediadistribution services. Individuals could see their friends' avatars andhear associated audio clips.

A venue could also periodically have the most popular or featuredpatrons possessing an avatar or avatar with audio being presented overthe jukebox controlled audio and video systems in certain exemplaryembodiments. These could be similar to an individual's introduction of aplaylist or music set.

The camera used for capturing the avatar in the jukebox could also haveadditional capabilities and/or be leveraged in a number of differentways, e.g., as set forth herein. For instance, the jukeboxes of certainexemplary embodiments may be configured to take photographs whileplaying music, thereby allowing patrons to engage with the jukeboxwithout interrupting the play of music. Multitasking operating systemsand/or functionalities may be provided for these and/or other purposes.

Alternative pictures not intended for avatar creation could be providedas a charged-for service. Patrons may pay for such images by providingmusic credits to the jukebox. This photograph taken by the jukeboxcould, in return for a number of credits, or cash paid via credit cardor bills or coins, or virtual wallet associated with individuals socialmedia account, be modified, printed, and/or distributed over, email, theInternet, a social network, to mobile applications, e.g., as set forthherein.

In-venue printing capability also may be provided. For instance, incertain exemplary embodiments, the jukebox may include within its form aprinting means allowing patrons to obtain prints of their photographsfrom the jukebox device after a short delay. Alternatively, a remoteprinting station controlled by the jukebox and used for printingphotographs and other materials (such as coupons, promotional vouchers,etc.) may be under the control of or at least in communication with thejukebox, so that these images may be printed on behalf of individuals,venues, advertisers, and/or others. Any suitable wired or wirelessconnection may be provided. For instance, a network printer may beconfigured, e.g., over a LAN or WAN connection, Bluetooth, and/or thelike.

Videos could also be paid for music credits or cash or credit or avirtual wallet account, etc., to allow patrons to take the video of themoment and to share this video via a social media website, email, andInternet link, and/or the like. Audio optionally may be captured alongwith the video, e.g., through a microphone provided to the jukeboxand/or synced from a remote source (e.g., a mobile device of thepatron). The synchronization may be facilitated by providing a common orshared timestamp service as between the various devices involved in thevideo and/or audio capture.

This video session may also be possible whether music is playing or not,thereby providing a second revenue opportunity for the jukebox device.For instance, the jukebox could earn money for the operator by playingmusic and selling photo services or video services or audio videoservices, all at the same or substantially the same time, e.g., throughmultitasking operations.

As it is possible to operate the camera within the jukebox at all times,and by employing an algorithm that compares recent images captured withthe current image, it is possible to detect the motion in front of thejukebox. This motion may be used in certain exemplary embodiments totrigger a particular attract loop, encouraging the passerby to engage ina music or other activity on the jukebox. This motion sensing trackingcould also trigger face detection services that would allow a portion ofthe observed image to be presented on the jukebox or on TV screensconnected to the jukebox in certain situations. In addition, or in thealternative, it may be possible to apply a filter or frame to theobserved image offering an example of what a photograph or video couldlook like if one were to be taken and paid for. Captured and/or printedimages may be incorporated into standard attract loops advertising thejukebox, karaoke, and/or photo booth features of the smart jukebox incertain exemplary embodiments.

Most jukeboxes are typically installed in locations with subduedlighting. It therefore may be desirable to supplement the availablelight when taking a picture with light from the jukebox. For example,based on the luminosity detected from the camera, the jukebox may incertain exemplary embodiments compensate its LED and/or other lightingsystem and, if required or desirable, use the light emitted from the LCDdisplay to supplement both the luminosity of the picture to be taken orvideo to be taken, thereby possibly improving the effective whitebalance of the picture to be taken or video to be taken. Of course,other image and/or video characteristics aside from or in addition towhite balancing may be adjusted, modified, and/or improved by alteringthe lights including, for example, color saturation, overall brightness,color tone, exposure, etc. It may also be possible to correct forambient light asymmetries, inadequacies, and/or the like in certainexemplary embodiments, e.g., by using the camera to detect or surmisethe existence of such problems and then instruct the lighting system(s)of the jukebox how to correct for them.

It is very popular to celebrate an event with a group of people usingsocial media. However, a jukebox provides an additional opportunity tonon-contiguous interactions to be associated with a single event. Forinstance, a baseball team could have won an important game that itwishes to commemorate with music and pictures. A first individual couldcreate the event, by identifying himself with credentials and creatingan event name. The event could have a theme assigned to it from a seriesof templates offered by the jukebox. In this example, the patron wouldselect a sports victory theme and give it a name such as “Finally beatthe Panthers.” Throughout the evening, others could go to the jukeboxand using credits or cash or a virtual wallet or the like, add musicselections, or photographs, or comments to the event.

In certain exemplary embodiments, each event entry may be performed aspart of a payment event. For instance, patrons could pay to take one ormore pictures or submit videos or commentary to the event, etc. Inaddition, or in the alternative, the creation of the event itself mayrequire payment. This payment may cover all, some, or none of thepossible subsequent activities that may be associated with the eventthroughout a night or event or duration of time.

This ability of certain exemplary embodiments to create a media log ofthe event by using the jukebox may allow a digital memento to be createdby the jukebox for a variety of experiences. The event could be anexperience that took place before convening at the location, eventstaking place in the location such as a singing contest, trivia contest,or other group activity.

The ability for the jukebox to be the repository for the event media andthen to post this media to social networks or to e-mail addresses ofspecific individuals may help create a record of the experience onbehalf of the group rather than by individual who then shares it withthe group.

In certain exemplary embodiments, users may identify themselves througha user name and password combination, an image presented to the camera,or an electronic message from a close proximity device, for the purposeof creating a virtual event and/or adding elements to the event.

In certain instances, a jukebox equipped with photo and/or videocapabilities may serve as a draw to individuals in a location toparticipate and share their experiences. The contribution of socialmedia need not be restricted to that captured solely at the jukebox. Forinstance, a jukebox photo booth application may allow a user to login orcheck in to the jukebox from a mobile device and participate in theexchange of entertainment media directly from one's own mobile device.This may in certain exemplary embodiments include the ability to submitmedia photographs, videos, text, audio, etc., to the jukebox repository,or to consume audio video text and images being projected from thejukebox in real-time or retrospectively. All of the social media sharingcapabilities may be possible from a mobile device that has checked intoa jukebox equipped with fully photo booth capability. Thus, capturing,sharing (through the Internet, email, a social networking site, and/orthe like), etc., may be enabled through both the jukebox and a pluralityof mobile devices at or away from the venue, in certain exemplaryembodiments.

A challenge exists in delivering jukebox distributed media to deviceswithin the location so that video imagery and/or audio is/aresynchronized. Audio, video, trivia, game data, and/or the like, maybecome disinteresting or unfair if the time synchronization is notmanaged effectively. In certain exemplary embodiments, the jukebox maybe equipped with a mechanism to synchronize its time and the time ofremote devices, e.g., using a network server or direct communicationsbetween devices. Additionally, because of the unpredictable latency ofwireless networks, it may be desirable for jukebox to discover a latencyoccurrence and to re-synchronize the timing, allowing all devices toonce again be presenting media in a sufficiently synchronized timeframe,so that the media experience is not compromised. Thus, it will beappreciated that certain exemplary embodiments may enable mobile devicesto check-in with a jukebox device and establish a time sync betweendevices over a WAN, WLAN, and/or the like, e.g., so that video, images,and/or audio may be distributed, displayed, captured, and/or otherwisemanipulated in an acceptable and appropriate time-synced manner.

Once checked in (e.g., identified to a social networking service asbeing present at a location based on, for example, transmission of asignal indicating the location and login credentials of the user),mobile devices may be able to participate in a virtual event, or toinitiate the creation of a virtual event, in certain exemplaryembodiments. This may allow others to submit song selections, audio,video, and commentary to the digital record of the event, for example.From a mobile device, this may take place at no charge, be funded by avirtual wallet associated with the account of the mobile device owner,etc.

Thus, it will be appreciated that using certain exemplary techniquesdisclosed herein, many people may be able to participate in an eventfrom a variety of different computing devices, thereby forming acollection of different sub-events or activities.

Certain exemplary embodiments described herein may be used in connectionwith the user interfaces disclosed in, for example, U.S. applicationSer. No. 12/929,466, filed on Jan. 26, 2011, which is herebyincorporated herein in its entirety. Furthermore, certain exemplaryembodiments may be used in connection with the designs shown anddescribed in U.S. Pat. Nos. D475,029, granted May 27, 2003; D616,414,granted May 25, 2010; D629,382, granted Dec. 21, 2010; D642,553, grantedAug. 2, 2011; Ser. No. 29/371,255 filed Dec. 14, 2010; and/or29/401,854, filed Sep. 16, 2011, the entire contents of each of which ishereby incorporated herein.

Although certain exemplary embodiments have referred to a karaoke and aphoto booth application in combination with a jukebox, it will beappreciated that the techniques disclosed herein may be used in anycombination or sub-combination. For instance, the karaoke, photo booth,and/or jukebox techniques disclosed herein may be applied to any type ofon-demand paid media kiosk or the like.

As indicated above, certain exemplary embodiments may feature tie-ins tosocial networking sites. For instance, karaoke contests may be viewedlocally, nationally, or even internationally (e.g., worldwide) viasocial networking sites or the like. People around the world could usesocial networking or other sites to vote for their favoriteperformances, and people can advance through a competition. Suchtechniques could even be used as a possible entryway to areality-television style competition to be aired on television and/orover the internet. The ultimate competition may be karaoke, live music,or otherwise based.

In certain exemplary embodiments, a patron may develop a list of karaokeor photo booth friends. This list may be generated automatically byscanning connections in a social network in certain exemplaryembodiments. In certain exemplary embodiments, the karaoke jukeboxsystem may enable patrons to communicate with their friends via SMS,email, social networking, jukebox-specific, and/or other messages. Incertain exemplary embodiments, a “buddy list” may be built and used forinstant communications. Patrons could issue karaoke challenges, meet-uprequests/messages/details, comments on photos, song or karaoke songsuggestions, etc. Messages may be sent automatically to a patronwhenever a friend has checked in to a location, signed up for aperformance, completed and/or shared a performance, etc.

In addition to possibly being able to buy a memento of a night out(e.g., a karaoke audio and/or video performance; a photo, video,slideshow; event package including songs and photos and/or videos;etc.), messages may be sent to patrons letting them know when theirsongs have been made available and possibly edited by an editor so thatthey can subsequently download them (e.g., for a price).

Certain exemplary embodiments relate to an entertainment centercomprising a computer capable of communicating with networks, whereinsaid computer is further connected to at least one display throughstandard analog, digital, or network-addressable displays, said computerbeing operable to interact with a remote device connected to one of saidnetworks in communication with said computer, said remote device beingoperable to accept a code and transmit said code to said computer, andwherein said computer can validate against a database or against analgorithm the validity of said code and, upon positive validation, saidcomputer is configured to allocate a monetary value or a credit value tosaid remote device. The remote device may be operable to browse contentcontained on said computer and said remote device may be furtheroperable to select and pay for said content using said monetary or saidcredit value, said computer may be operable to reduce said monetary orsaid credit value upon a selection by said remote device. The code mayinstead or in addition be sent to the remote device and entered on thecomputer.

Certain exemplary embodiments relate to an out-of-home entertainmentcenter coupled with at least one Internet-based messaging system and/ora social networking site and coupled with at least one remote device,said remote device being connected to the out of home entertainmentcenter by a wired or wireless local area network or through theInternet, wherein the use of some of the entertainment center servicesby said remote device causes said entertainment center to send messagesto said at least one Internet-based messaging system. Connecting thesystem through the Internet may require a user to input a code to theremote device that uniquely identifies the entertainment center.

Some of the handheld devices referred to herein may be those described,for example, in application Ser. No. 11/902,790, the entire contents ofwhich is incorporated herein by reference.

The present disclosure has used certain terms that should not beinterpreted as limiting the invention to a particular embodiment,hardware components and configurations, software configurations, etc.For example, many features and examples have been described in relationto their existence within a bar, pub, or other environment. However, itwill be appreciated that the features present in the exemplaryembodiments of the present invention are adaptable for use in anylocation where a jukebox (or multiple jukeboxes) may be located.Similarly, while certain features and functions are described withreference to usage by “users,” “owners,” “operators,” “patrons,” etc.,it will be appreciated that these terms are generic and may, in mostcases, be used interchangeably depending on the embodiment chosen andthe feature employed. For example, while it may be advantageous to limitthe initial song selection to owners and/or operators, in certainexemplary embodiments, patrons may play a role in the initial songselection. It will be appreciated that the term “display” includes, forexample, monitors connected to computers directly or remotely, orembedded ICs such as IP TV technology. Displays may be networkaddressable. Also, standard digital signs (LED based) also may beconsidered displays and/or may be provided as network addressabledisplays.

Although certain exemplary embodiments have been described in connectionwith out-of-home locations, it will be appreciated that the techniquesdescribed herein may be adapted for use in an in-home or personaljukebox device, e.g., that has a suitable connection to the jukeboxnetwork or is configured for stand-alone operation.

Moreover, although certain exemplary embodiments have been described inconnection with in-home and several illustrative out-of-home scenarios,the exemplary techniques described herein may be used in connection withdifferent locations and/or events. In general, the example techniquesfor blending high quality audio with ambient audio and/or potentiallyuser-generated video described herein may be used in connection with anykind of live event where a recording might be desirable such as, forexample, at concerts; plays and musicals; speeches, rallies, orprotests; retail or other shopping events; newsworthy events or eventsthat are reported as news; etc.

In the public or concert performance context, for instance, certainexemplary embodiments provide a means for a performer, record label,school, production company, or other suitably qualified party to allowrecordings of a concert and optionally to charge a for those recordings.It currently is common for people attending a concert to use the videorecording capabilities of their mobile devices to record portions of theconcert. While the audio and video quality oftentimes is relatively low,the recording nonetheless is seen as an important memento of the event.And even though the audio and video quality oftentimes is relativelylow, the person or persons recording the performance may not have thelegal bundle of rights necessary to do so. Thus, it will be appreciatedthat it would be desirable to also enable the recording of performancesor events in a way that promotes user-generated content while stillrespecting the rights of those rights holders and also potentiallyoffering them monetary compensation for granting licenses in and to therecordings and/or new works created via the blending approaches.

In certain exemplary embodiments, an artist, booking agent, venue staff,school teacher, or other authorized person may contact a recordingservice, e.g., run by the assignee of the instant invention, to requestthat recording and blending services be made available at a particularevent. The identified event would be identified, and an entry for theevent would become present in a recording schedule used by mobile orother devices equipped with a custom recording application. The customrecording application may be downloaded or otherwise installed for a feein some scenarios and may be used for unlimited or some limited numberof subsequent events. In certain exemplary embodiments, the applicationmay be free or available for a nominal fee, but users may be charged forrecordings, e.g., by song, number of songs, or duration of time.Different pricing tiers may be set for different songs, artists, labels,song lengths, event types, etc. For instance, school events may be lessexpensive than Indie rock events, which may be less expensive than arecording of some or all of a Rolling Stones concert. In some cases, aspecial labeled version of the recording application may be created,enabling branding and messaging to help market the artist or otherartists on the same label or representation.

In one exemplary use case, a user buys a custom summer tour app for apredetermined amount of money (e.g., a Katy Perry Summer Tour app for$10.00). This application permits the user to video three songs in oneor more shows. When the tour or show ends, or when the three videos havebeen captured, a link to the video is provided, with the video includingactual audio from the performance mixed in with some ambient crowdnoise.

Certain exemplary embodiments may include one or more upload systems.Similarly, the recording system may receive a high quality (e.g.,digital) audio feed of the performance and possibly also backgroundacoustics of ambient noise within the venue such as applause andcheering. A mixer or mixing board may be provided on-site to receivesuch inputs. The mixer or mixing board may be as simple as a mixedbalanced line out fed in to the recording service's upload device (e.g.,computer, laptop, or other combination of suitably configured hardwareand/or software). The upload device may forward either digital versionsof the live audio feed, mixed songs (e.g., that have been post-processedafter the performance or processed in real-time or substantially inreal-time), or multiple unmixed or partially mixed audio streams forlater assembly in final mixing. The upload device may be configured toidentify the performance (e.g., with a name, date, time, and/or uniqueidentifier) and to characterize the method and format of upload material(e.g., file format, whether the audio stream(s) is/are raw or fully orpartially mixed, source device(s) for the audio stream(s), etc.). Videoalso may be gathered and uploaded via the same device in certainexemplary embodiments, and this type of and/or other related informationmay be provided. The uploaded data may be stored to a storage locationin the cloud. The cloud service may be configured to archive theuploaded material for subsequent processing.

A performance archive system located in or having access to the cloudmay process inbound or uploaded audio streams and, where necessary ordesirable, add relevant metadata to organize the received audio. Forinstance, depending on the upload stream, audio may be identified aslead-in or actual song performances. A matching system may be configuredto identify contiguous audio streams, and individual identification ofsongs therefore may not always be required.

Similar to as described in the karaoke jukebox related examples above,audio and/or video may be gathered from audience members using anapplication on their smart phones, tablets, or other computing devices.A mobile user having a device equipped with the recording application ora specially designed application for this particular artist may, forexample, purchase or qualify for the right to record a performance. Asindicated above, the recording may be limited in some way, e.g., to aparticular number of songs, a total amount of time, etc. Theapplication, running on or accessible via the device, may interface withan embedded or attached video camera to create a digital recording of aperiod of/or time during the performance. If the mobile user issatisfied with the recording, (e.g., from reviewing it on their mobiledevice, or from his/her assessment of the video captured, etc.), themobile user may choose to save the recording. This may cause therecording to be copied to the cloud for archiving and matching againstthe performance audio. It is noted that there could be many users for agiven performance, with each user possibly submitting his/her own clipsfor matching.

The recording system cloud service may ingest inbound mobile user mobileclips and (if present) metadata concerning the user and rightspurchased. This material may be archived (e.g., stored to a database) asperformance mobile video and audio recordings, and associated metadata(as appropriate and as available).

Based on timestamps and metadata received from both the upload feed, orcalculated from the time of an upload feed, and metadata timestampsreceived within the mobile user video feed, a matching process maybegin. The audio data files of the mobile video and the upload video maybe compared to one another using a pattern matching or algorithm, e.g.,with time sequencing capabilities. When the “best” match is obtained,audio segment time delimiters may be used to create a new video with arevised audio mix. That is, transitions between songs, sets, spokenacknowledgements, etc., may be detected or otherwise marked, and used asdelimiters for different portions. In addition, if it is determined thata particular user has “missed” the beginning, end, or intermediaryportion of an otherwise contiguous clip (e.g., because the user did notrecognize the song being played, the user's mobile device ran out ofbattery, the user was too slow pushing a record button, etc.), the“missing” audio and/or video may be supplied to the segment. Thismissing data may be supplied by others who managed to record that part,from a “house” or “official” source, etc. Timestamps may facilitatedetection of missing parts and location of those portions that are to beadded.

Similar to the above, in the audio mix, the audio from the device may bereplaced with up to 100% of the uploaded audio from the performer'smixing board, which represents very high quality audio. In some cases,it will may desirable to have some audio from the mobile device, e.g.,recording the patrons' reactions to, or comments on, the performance,etc. The amount of mobile background audio included could beconfigurable at the mobile device in certain exemplary embodiments.

Once the remixing process has taken place, a new mixed song coupled tothe mobile video may be used to produce a digital video file that isarchived on the cloud server. The address of this video segment may beindexed for distribution to the mobile patron and/or others who qualifyfor the download. Once the patron's mobile video has been processed, anindication may be sent to the mobile device on which the videooriginated alerting the user that the video has been processed. Thislink to the new processed video may be available online for streaming orcan be downloaded, depending on the rights authorized by the artist orartist representatives, for example. The link to the video could bee-mailed to other devices, e.g., depending on the rights permitted bythe artist. Other individuals (e.g., fan club members, school boostersor parents, etc.) also may receive email or other links. In certainexemplary embodiments, the file, a portion thereof, or a link thereto,could be posted to or disseminated a public service such as a socialnetwork site (e.g., as a posting on the performer's page, as a Tweetfrom an authorized account, etc.).

Thus, it will be appreciated that the example techniques that are beingapplied for karaoke may be used for non-jukebox and non-karaoke eventssuch as, for example, certain live performances or shows. Certainexemplary embodiments therefore relate to the creation and optionaldistribution (possibly selling) of new content, including high-qualityaudio synched with a video captured on a mobile device, with that newwork optionally being paid for via a mobile application.

Example details as to how this may be accomplished will now be explainedin connection with FIGS. 24-30. However, it will be appreciated that thevarious hardware combinations and configurations, and process flows,that are disclosed represent only one way which the embodiments may beconstructed, and other combinations, configurations, process flows,and/or the like, may be used in different exemplary embodiments. FIG. 24is a flowchart demonstrating steps in recording a performance or otherevent in accordance with certain exemplary embodiments. An artistperformance date is planned in step S2402. If recordings are notallowed, e.g., as determined at the decision point 2404, then theprocess waits for the next performance 52406. Otherwise, if recordingsare allowed, the several steps may be taken to prepare for therecordings. For instance, in step S2408, a sub-process for enablingrecordings in applications is undertaken. This may include, for example,adding the event to a list of events, potentially including informationabout the event (e.g., artist name, location, start/end time, cost data,etc.). Some or all of this and/or other associated data may be stored ina database. At step S2410, a decision is made as to whether a customizedapplication is to be provided for the particular event. If so, a customapplication may be built in step S2412.

The custom application may include, for example, branding and/or alook-and-feel appropriate for an artist, customized advertisementsgeared towards a particular target audience, etc. If there is no specialapplication, or once the custom application is built, the process waitsfor the performance at step S2416. At the venue, for example, the uploadsystem is prepared, e.g., in step S2414. This may include, for example,connecting a computer system (including suitable hardware and/orsoftware) to a mixing board, ensuring that potentially secureconnections to a remote storage location are made available (e.g., overan Internet connect), etc.

FIG. 25 is a block diagram of illustrative components of an uploadsystem in accordance with certain exemplary embodiments. As shown inFIG. 25, audio lines from the band performing 2502 are fed to a mixingboard 2504. This may include, for instance, output from microphones,guitars or guitar amplifiers, keyboards, etc. The output from the mixingboard is then fed to a digital or other upload device 2506 that storesaudio data to a remote storage location (e.g., in the cloud). Forinstance, raw audio feeds 2514 may be fed as a part of a live feed 2516to a first network storage location 2518. Mixed audio data 2508 (e.g.,including audio for multiple instruments, microphones, and/or othersources) may be stored as a mixed song 2510 that is uploaded to a secondnetwork storage location 2512. Similarly, unmixed or partially mixedsongs 2520 may be slit into multiple song tracks 2522 and uploaded to athird network storage location 2524. The digital upload device may beproviding separately identifiable songs, a continuous live feed stream,or individual tracks to be merged in the cloud. Once received at thenetwork storage device at in the cloud, the performances may bearchived, potentially allowing future matching with submitted videorecordings.

FIG. 26 is a partial schematic view of a performance archive inaccordance with certain exemplary embodiments. As shown in FIG. 26, anetwork storage location 2602 includes a segment identifying and songparsing module 2604. The segment identifying and song parsing module2604 operates on performance audio and data records stored, e.g., in adatabase including multiple performance audio and data records stored.The example performance audio and data records stored 2606 shown in FIG.26 includes a plurality of songs 2608 a-n. Optional lead-in audiosegments 2608 a-n are provided for some or all of these songs 2608 a-n.Optional lead-out audio 2612 also is provided. As alluded to above,optional lead-in audio 2608 and lead-out audio 2612 may be provided forsome of all of the songs 2608. This or separate lead-in and/or lead-outaudio may be provided for an event as a whole or in part, e.g.,including a set, group of songs (such as a medley, group of continuousor discontinuous separate songs, certain items selected for recording bythe artist, label, or mobile device users, etc.), or even an individualsong. Although not expressly shown in FIG. 26, metadata may beassociated with each of the segments 2608, 2610, and 2612, e.g.,indicating timestamps (e.g., for start and end times), lengths, dates,the source of the data (e.g., from the mixer, raw input streams, from auser, etc.), and/or the like. The upload system that is located withinthe venue or at the event may submit data that is either stored as acontiguous data stream. If metadata or detectable audio cues areavailable, the data set may be identified with a segment ID and songsmay be parsed with the identification of audio type. Possible audiotypes include lead-in, actual song, lead-out, etc. The audio record maybe time stamped based on information provided from the performance venueand the receipt time at the cloud server.

FIG. 27 is a simplified schematic view of a mobile user using a mobileapplication to record a portion of a performance in accordance withcertain exemplary embodiments. A venue 2702 as shown in FIG. 27 shows aband performing before an audience, with multiple speakers provided inthe location. A mobile user using a mobile device 2704 may be able torecord video of the band performing. A time or other counter mayindicate how much of the event has been recorded, e.g., after the userpresses a record or other similar button. The user may press a save orother similar button to cause the mobile device to transmit anaudio/video clip 2706 to a network storage location 2708. In certainexemplary embodiments, the audio/video data may instead be streamed tothe network storage location 2708.

Thus, using a specialized recording application on a mobile device, apatron may select the record feature and, if the user has beenauthorized to take a recording, either through the purchase of recordingrights or, because of the performance being available at no charge fromthe performer, the mobile device may begin recording all video and audiosubject to a potential time restriction. Users may be instructed tobegin recording no more than X seconds before song, and to end recordingno more than Y seconds following a song (which may be an automaticcutoff in some instances). Alternatively, or in addition, someperformances may allow for recording without song delimitationrestrictions, but rather allowing a contiguous segment, or continuoussegments of a performance.

FIG. 28 is a partial schematic view of a performance archive foruser-based recordings in accordance with certain exemplary embodiments.As shown in FIG. 28, the network storage location 2802 may includemobile clips and/or associated metadata 2804 for one or moreperformances. The storage format (e.g., the database) and/or themetadata stored therein may be similar to that described above, e.g., inconnection with FIG. 26, for each performance audio and data record2806. In addition, or in the alternative, unique clip and/or patronidentifiers may be provided. As shown in FIG. 28, for example, multipleclips 2808 and 2810 are provided for multiple patrons a-n. The databasemay be organized such that clips for common events are stored in closerelative proximity to one another (e.g., in a common table or commondirectory), or otherwise linked together, in certain exemplaryembodiments. Similarly, clips for a single user may be stored in closerelative proximity to one another (e.g., in a common table or commondirectory), or otherwise linked together, in certain exemplaryembodiments.

For each mobile device equipped with the specialized application and theappropriate rights to record, each recorded segment from the pressing ofthe record to the pressing of the and record button may have the videoand audio submitted to the network storage cloud service. The videoresolution and audio quality of the submissions may vary because of thecapabilities of the mobile device or the bandwidth necessary to transferthis data. Submissions may be archived, e.g., by performance andpossibly in time sequence or other order, as they are received incertain exemplary embodiments. The indexing and archiving may besufficiently capable of conveying an indication as to the general timethe recording was made to facilitate matching. These archives may betreated as individual clips, and may be matched against the storeduploaded performance audio data received.

FIG. 29 is a schematic view showing mobile audio clip matching andre-mixing techniques in accordance with certain exemplary embodiments.As is shown in FIG. 29, a first clip for a first patron 2902 undergoes amatching process executed via a matching module 2904 of a computersystem (e.g., which includes at least one processor and a memory forexecuting instructions tangibly stored on a computer readable storagemedium). The matching module 2904 attempts to find a song 2906 and anyrelated lead-in or lead-out data 2908 and 2910. As shown in the FIG. 29example, the data for a specific performance (Performance X) may beretrieved and searched. This may be facilitated by metadata associatedwith the clip, e.g., including some or all of the performancename/identifier, date, time, and/or other informational aspects. In theFIG. 29 example, the matching module 2904 determines that the first clipfor the first patron 2902 corresponds to song 1 28906 a and a portion ofthe lead-in audio 2908 b for the second song 2906 b. That information tobe passed to the audio remixing module 2912, which can then retrieve thehigh quality audio for the first song 2906 a and optionally pre-pend theproper lead-in audio 2908 a. The lead-in audio 2908 b for the secondsong 2906 b may be removed. The mixing may take from 0-100% of theambient background recording from the clip and/or from other sources andmix it with appropriate amounts (0-100%) of the high quality sources.The newly re-mixed audio may be combined with video from the patron andused to generate a mixed song with mobile video 2914. This new work maybe downloaded or otherwise made available to the user and/or others. Itis noted that some or all of this and/or other processing may beperformed in the cloud.

Once the new video was created through a remix of the audio from theuploaded source and the mobile submitted source, the new video may bestored on a cloud server with a unique address (e.g., GUID). In somecases, the video may be controlled by the performer and only accessiblethrough a subsequent transaction. For instance, the patron who hadpurchased the rights to record one or more segments of the performancemay have access via a credential authentication to stream this clip toany device that supports authentication and audio/video playback.

In some circumstances, the performer may be willing to relinquish therights to control the new video creation and would allow the actual fileto be downloaded rather than streamed, e.g., upon the payment of anadditional fee. For instance, a user-recorder may be incentivized tosell his/her recording by being rewarded with some monetary credit basedon downloads of his/her recording. In other cases, the user-recorder mayreceive no credit, but rather licensing fees charged to communitydownloaders may be transferred to the original rights holder(s) and/orfacilitators of the upload/download/matching system. These and/or otherrevenue sharing schemes also may be made available for thekaraoke-jukebox embodiments discussed above.

FIG. 30 is a schematic view showing a mobile video file being viewedfrom a cloud or other network location in accordance with certainexemplary embodiments. Unlike in FIG. 27, the mobile device 2704 isshown in a playback or “media ready” mode, e.g., after the audio and/orvideo clips are matched and mixed, and a coherent audio and/or videoclip is generated. In that regard, the user may access the mixed songwith the mobile video 3002 from the network storage location 3004 byaccessing a link to the video stream or file 3006. In certain exemplaryembodiments, the combined video may not be generated until requested bya user.

Although this may require temporary bursts of processing power, spacesavings may be generated, as not all clips would need to be combinedimmediately. In certain exemplary embodiments, a user may be allowed toselect which one or more audio clips are to be combined with which oneor more video clips, etc., specify levels for high quality audio versusmobile audio, etc. The process to match the uploaded performance withthe submitted mobile video clip may take some time. In some instances,the uploaded performance may only be available hours or even daysfollowing the performance.

Particular hardware combinations and configurations are disclosed whichrepresent only one way which the embodiments may be constructed, andother combinations and configurations may be used in different exemplaryembodiments. For instance, central servers may, in some exemplaryembodiments, be comprised of one or more servers acting together orseparately to coherently provide the full range of services necessary toenable a functioning jukebox. For example, a cluster of servers maycomprise a virtual central server, with one server providing media,another tracking membership, still another processing licensing, etc.

Similarly, the local servers described herein may be incorporated intothe jukeboxes. For example, the local servers may appear to functionindependently, even though they exist as part (e.g. partition) of anintegrated mass storage device within the jukebox. Indeed, as hard disksbecome larger and less expensive, they may preferably serve thefunctions of local servers.

Also, although the term “song” has been used sometimes in theabove-description, this term is not intended to be limiting to the scopeof the invention, and any instance or instances of media (e.g., song,video, song/video combination, data, information etc.) can be used inany embodiment herein and still fall within the intended scope of theinvention.

It will be appreciated that the screen shots and software arrangementspresented herein are only one exemplary method for organizing anddisplaying the features disclosed herein. Other configurations arepossible and are therefore contemplated herein. In this vein, thetechniques disclosed herein may be implemented by any suitablecombination of hardware, software, firmware, and/or the like. Thevarious modules, arrangements, programs, etc., may be implemented inthese and/or other ways.

While the preferred aspects of the invention have been illustrated anddescribed herein, it will be apparent to one of ordinary skill in theart that various changes and/or modifications can be made. Thus, thespecific description herein is meant to be exemplary only and is notintended to limit the invention beyond the terms of appended claims.

What is claimed is:
 1. A method of generating a file corresponding to aperformance in which a performer sings a song with backupinstrumentation played from a stored audio visual data file, the methodcomprising: receiving audiovisual data of the performance captured froma portable user device, the audiovisual data including first audio dataand first video data; receiving second audio data of the performance,the second audio data including audio data collected from a microphonenear the performer and including vocals of the performer and audio fromplaying the stored audio visual data file; digitally combining the firstaudio data and the second audio data such that the first audio data ispartially replaced with the second audio data in order to produce a newaudiovisual data file with video content from the received audiovisualdata synchronized with the second audio data; and providing forsubsequent performing of the produced new audiovisual data file undercontrol of a jukebox while tracking rights and/or royalty sharingassociated with the new audio visual data file, wherein the rightsand/or royalty sharing associated with the new audio visual data fileinclude rights and/or royalty sharing associated with vocal eliminationand replacement and are different from rights and/or royalty sharingassociated with the stored audio visual data file.